FilterSecurityInterceptor and request parameters (again)

I'm posting a new topic, though there is one with a very similar name. Unlike that post's scenario, my scenario involves authenticating based upon performing some validation of request parameter values.

Let me explain the scenario.

I plan to have the traditional UsernamePasswordAuthenticationToken to grant full access. However, there is an exception case that I'd like to cover. I'd like to be able to provide a link to a Change Password page, but have this link adorned with the necessary parameters to match up within the database. This link should be good only for that one page. I'm not sure how best to implement this within the framework. Any suggestions?

I have a similar scenario involving a weak cookie-based sign-in. This weak sign-in is an implementation of the "remember me" functionality. What I'm doing now (outside the framework) is dropping a cookie with an id and a random token value. This token value is stored in my authentication repository and is good for one sign-in. The token value is regenerated each time to minimize the exposure if a cookie were intercepted. Sign-in in this way, enables the less secure features to be accessible. However, access to sensitive areas requires a form sign-in.

I'm curious to know if there is a good way to combine all these authentication methods compatibly. I have read the manual and some of the related threads, but its not quite clear to me as yet. Any help would be greatly appreciated.

Thanks,
Bill

Unfortunately I have been snowed under with another project and will be for at least another week, so I haven't had time to wrap up the two related features of anonymous users and remember-me functionality. The acegisecurity-developers list had a detailed post on the remember-me functionality if you need this urgently. I would also be happy to review any design before you coded it, especially if you wanted to contribute it back to the project.

At first glance I'd consider coding a new AssumedIdentityProvider which works with an AssumedIdentityAuthentication, with a corresponding Filter which creates the AssumedIdentityAuthentication and puts it onto the ContextHolder. Then modify SecurityEnforcementFilter to recognise an assumed identity and launch the AuthenticationEntryPoint in the event of an AccessDeniedException (because access denied for anything less than a full login could be due to insufficient login integrity and the user should get a chance to fully authenticate). In this sort of situation it would be appropriate for SecurityEnforcementFilter to have a protected boolean isAssumedIdentity() method which can inspect the Authentication and return true/false as appropriate. The basic implementation might check the class against a SecurityEnforcementFilter.assumedIdentityClass, thus not creating a hard-coded dependency on AssumedIdentityAuthentication (although that would be the default). Hopefully this gives you some ideas if you needed to proceed right away, otherwise give me a little time and I'll take care of it...

Ben,

Thanks for your reply. I will let that resonate in my head while I re-read your documentation once again. I'm pretty sure this is mostly trivial once I understand your framework -- just sounds a bit intimidating on first blush.

I was aware that you were working on a remember me feature, just wasn't sure it was quite like mine. Mine actually generates one-time-use cookies that have mirrors in the database. I borrowed the concept from reading this link:

http://fishbowl.pastiche.org/2004/01..._best_practice

Will your implementation be somewhat similar?

Thanks again for your always-prompt replies in this forum.

Bill

The e-mail thread that talks about Remember Me refers to AppFuse, which uses the same method that Charles describes.

E-Mail Thread: http://sourceforge.net/mailarchive/f...forum_id=40659

AppFuse Implementation: http://raibledesigns.com/page/rd?anc...t_iii_remember

Thanks, Matt.

I actually do have the "remember me" stuff implemented, its just that I have done so through Spring interceptors. I have a cookie interceptor and even a token interceptor which take principal and credentials out of a cookie or out of the request respectively. It then "weakly" signs you in by storing this into the session. And of course, the cookie and token are good for one time only.

However, if I move to the Acegi framework, I want to refactor to do it the Acegi way. I was asking Ben how these concepts could be applied within his framework. I had read the "remember me" post elsewhere, but didn't fully understand the concept I've been calling token-based.

But anyway, thanks for the links again to the discussion and the sample implementation.

Bill

I too am a little troubled by the database requirement, but it's the only way to achieve a one-time use. My earlier proposal included a "last interactive authenticated date" to be presented in the cookie, so voters could consider how stale the authentication was. This model avoids the need for a database.

Different applications will have different needs, so a pluggable approach will be provided so any "remember me" and "anonymous" login implementation can be used.

More thoughts on this.

I'm trying to get my head around the "assumed identity" approach as well as the notes mentioned on the thread that Matt reacquainted me with.

To summarize, I have two features that seem outside of Acegi. The "remember me" functionality which really just "weakly" signs someone in. To me, this means that they are known and have privileges that are in context with who they are, but not strong enough to access the sensitive areas.

The other feature is the token-based sign-on using query string-based credentials, but I think I may need to re-think that idea. Originally, I was trying to figure out how to double opt-in a user after their initial registration. In this scenario, the account would still be inactive until they hit a link that I provided which unlocked their account. But perhaps I'm overthinking this -- perhaps that link should just hit a controller which deciphers the credentials, activates the account, and stores the authentication into the context. Would this be reasonable?

As for the "remember me" functionality, that is not so simple. I'm still trying to understand the moving parts to the "assumed" identity proposal. Does it still use the same Authentication structure, just with added information that the authentication was cookie-based? I guess I'm looking for more understanding of what additional classes I might need to implement. I think I understand the concept, just not sure how to fit it in nicely within the architecture.

Any further help would be appreciated.

Bill

I think the controller is the way to go, perhaps using the UserDetails.isEnabled() method recognised by DaoAuthenticationProvider.

I was initially intending to extend Authentication to represent a "weakly authenticated" principal. However, with the benefit of additional time to think about it, I think a separate AuthenticationProvider and corresponding Authentication implementation would make more sense. This makes it easier to create additional AuthenticationProvider-Authentication implementation pairs for additional or customised use cases.

Thanks for the reply.

So I take it you are working on this then? I hate to ask, but how long before we might see something?

I was actually thinking of taking a shot at this today. And I was thinking along the lines of adding a quality to the Authentication such that you could tell that it was weakly authenticated. I probably don't know the architecture well enough to get any more creative.

I now understand the need for an additional filter to place the weak authentication into the SecureContext. I just assumed that it'd be easier if this would be an extending version of the Authentication.

If I come up with anything, I'll run it past you.

Bill