On Wed, Jun 17, 2009 at 10:44 AM, Les Hazlewood<[email protected]> wrote: > Fair enough, although this does take quite a bit of effort to set up > compared to the other approach, which I have to say I've used successfully > on many commercial web sites with no ill-effect. That doesn't mean the > existing approach is the best it can be, it just means that, as is the case > of so many things in the security world, that it hasn't been exploited yet > on anything I've been involved with. There is _always_ room for improvement > in a security framework. > So, do you think 1) this paradigm could be easily incorporated into the > framework in a 'hands off' approach where it would work out of the box with > no required configuration and 2) if so, should it be the default > implementation used at startup?
No, I don't think it can be easily implemented in plain Shiro. The reason is the same as to why Shiro's Realm API is read-only: since Shiro cannot rely on any particular persistence model to exist, it's difficult to implement any more complex server-side authentication, identification or verification logic that would work out-of-the-box. Since I'm not bound to these limitations (the security module I'm working on requires JPA persistence) I can implement it fully as a drop-in functionality - users of the library won't even need to know how it works. > If the onFailedLogin and onSuccessfulLogin methods are not suitable, I'd be > more than happy to add a 'beforeLogin' method to the interface if you think > that would be sufficient. This would provide proper AOP-ish 'around advice' > for an authentication attempt. > Interestingly enough, both the RememberMeManager and the > AuthenticationListener are nearly identical. I think if we add a > 'beforeLogin' method it should go into the AuthenticationListener interface > and the RememberMeManager should just extend that interface. Anyone have > any objections on this? Even adding onLogin won't help me since I want to do something after a remembered identity was retrieved. But yes, I see a lot of custom logic dealing specifically with rememberme when it mostly looks like an authenticationListener (except for the added getRememberedPrincipals). So I think making RememberMeManager extend the AuthenticationListener is a good idea. > If you think this is a good approach and would allow you to do what you > need, please open a Jira issue and I'd be more than happy to push it > through. If this won't allow you to do what you desire, please let me know > why not and we can see how other mechanisms might be made available to do > what you need. At the end of the day, you have the ability to create > Subject instances however you want via a custom implementation of the > SubjectFactory interface (which is still in flux and might change to reflect I was going to write that I think my best short term approach is to override the DefaultSecurityManager which I didn't particularly like because it would have created a lock-in for users, but yes I see that SubjectFactory is new and might be exactly the extension point I need. I can use the default RememberMeManager exactly as intended and keep the rolling tokens separate, then use a custom SubjectFactory that will do the token reading and comparison and invalidate the remembered identity as needed. Thanks for that - I've been using 0.9 javadocs so I missed SubjectFactory but I'm looking at trunk source now. Kalle
