jcaptcha integration

[marc antoine garrigue]

Hi,
I'm trying to integrate jcaptcha and acegi.
First of all, what a great framework! Many thanks and congratulations to the acegi team!

Problem :
Authenticating an user as human is a security matter but not an identity one : you may be human and anonymous, or human and identified. These two notions are independent.

Forces :
-It would be great to use the same security management framework to enforce both concerns (identity AND humanity).
-basically, humanity of a user would be implemented by a flag added to its current identity (even if its identity is ANONYMOUS) without modifying it.
-Adding some custom attributes to identity would be great, like the number of human restricted ressources requested, that may be checked afterwards to decide wether the user needs to re-authenticate

A possible solution implemented with acegi would be :
-Implement a CaptchaAuthenticationProcessingFilter that checks a challenge response and flag the current Authentication.
-Implement a CaptchaSecurityEnforcementFilter and a CaptchaVoter that checks the flag and redirect to a custom captchaAuthenticationProcessingFilterEntryPoint if failed.

Questions :
-Does this solution sounds good? does it breaks the spririt of the acegi framework?
-How to implement the flag stuff ? : i can't find a way to add some information to an existing authentication.

Thanks
MAG

[Ben Alex]

For the benefit of the community, this page explains what Captcha is: http://www.javaworld.com/javaworld/j...7-captcha.html.

The net.sf.acegisecurity.securechannel package was designed with human user detection in mind, along with enforcing SSL security. I took the view that it was more a channel security issue than tied into the authentication process. ie like SSL/TLS/HTTPS, not like user bob or user jane. The advantage of taking a channel-based approach is you can implement it with just a list of URI patterns that should be "human users only". There's no need to introduce the notion of human detection elsewhere within your application. I'd therefore suggest you write a ChannelProcessor that works with the HttpSession and Captcha's internal classes (ie don't go all the way through to the JAAS layer for something that doesn't require it in the context of Acegi Security) to obtain the image etc.

Using an AuthenticationProvider would probably be possible, but it would conflict with the traditional notion of authentication representing a principal. Thus, your AuthenticationProvider would need to "decorate" an existing Authentication. It's all a bit ugly, in my view, compared with using the secure channel approach suggested above. The only possibly advantage is you could use ROLE_HUMAN inside non-web protected resources, such as MethodSecurityInterceptor. Although, if that became required you could easily achieve it by using secure channel and having the processing filter set a property inside the ContextHolder.getContext().setIsHuman(true).

This is actually on my TODO list, so if you get something working, please consider contributing it back as I know others would find it useful.

[marc antoine garrigue]

Thank you very much Ben!

I will have a deep look into the securechannel package, but it seems to provide access to the required objects.

I totally agree with your point, it seems more adequate to use the Channel stuff, since humanity and identity are two different concerns, this securechannel implementation would provide a clear separation of concens.

Although, if that became required you could easily achieve it by using secure channel and having the processing filter set a property inside the ContextHolder.getContext().setIsHuman(true).

This is actually on my TODO list, so if you get something working, please consider contributing it back as I know others would find it useful.

Are you talking about the Context modification ( the setIsHuman method?) or about the whole jcaptcha integration part?
Thanks again. I'm going to implement the jcaptcha secure channel. I do will contributing it back, i'm a jcaptcha team member, so this will be in our next release .

Best regards
MAG

[marc antoine garrigue]

I ve managed to build a sample around the contact sample application.
I've wrote a CaptchaChannelProcessor, that
-checks the captcha response if found and update the HumanSessionState according to the result
-checks the SessionState if required, and if not redirect to the CaptchaChannelEntryPoint.

-A single class handle both captcha response validation and humanity check. I think it would be better to have a separate class (but which one?) to handle the validation stuff.

-We usually see four types or security constraints around humanity :
Check every request
Check once and recheck after X requests
Check after Y requests
Check once for a session
In the current implementation, the 4 keyword associated with those 4 contraints are handled by a unique class. Is it better to split them? ( it seems to be a cleaner design but with a little overhead for each request)

- How to properly forward post arguments after the redirect to entry point? (my implementation only handle the query string)

-What are your plans concerning the Context extension ? I currently handle the HumanSessionState in a session object with two attributes :
boolean isHuman
int numberOfServedHumanProtectedRequests

Thanks a lot
MAG.

[Ben Alex]

Since 0.8.0, context handling was refactored to be a lot more user-friendly support these sort of enhancements. I use these extensions myself in an application to store the current WebSite being processed in a virtual hosting environment, and retrieve the current Subscriber being processed in that same situation (well, actually that comes from a SecureContext implementation that queries it from the container Authentication.getPrincipal(), but we're getting a little off-tracking...).

You can easily extend the SecureContext interface to a CaptchaSecureContext interface, and extend SecureContextImpl to a CaptchaSecureContextImpl. You define the target Context to use against the HttpSessionContextIntegrationFilter.context property.

If you would be happy to share what you've already written, I'll be pleased to use it as a guide to adding it into Acegi Security. I'm not sure 100% on the approach to use, but I'll ensure it reflects the four requirements you mentioned. If you're happy to contribute, please just post what you've done here or to the acegisecurity-developer mailing list.

[marc antoine garrigue]

You can easily extend the SecureContext interface to a CaptchaSecureContext interface, and extend SecureContextImpl to a CaptchaSecureContextImpl. You define the target Context to use against the HttpSessionContextIntegrationFilter.context property.

Ok i'll try this one and integrate it with my captcha channel implementation.
I will add a Humanity object to the CaptchaContext.

If you would be happy to share what you've already written, I'll be pleased to use it as a guide to adding it into Acegi Security.

I will be very happy to share my code! it will come soon!