> > Still not seeing the difference? Ok, let's take a real world example. > Bank of America's website remembers your username on that computer > (ip) only. If you move to a different location (say you suddenly > changed countries), it'll ask you a simple security question *before* > it gives you a chance to type in your password - so the "remember me" > works as an extra security feature rather than weaker form of > security. Obviously simply accepting the given client-side identity is > not enough. If you type in the wrong password, the implementation can > invalidate your remembered identity on the server. If somebody > intercepts your identity cookie it won't be valid anymore on the next > try. You can also better protect against systematic attacks since the > assigned key is unique (rather than the same encrypted identity) so > all keys can be invalidated at once.
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? Are you suggesting I'd do something like > SecurityUtils.getSubject().login() as part of > RememberMeManager.getRememberedPrincipals()? That doesn't sound like > the right approach to me. I completely agree and goes to what I was saying about an authenticated state vs a remembered state - I think an automatic login calls that are not manually initiated by a human is (usually) a bad thing. > I mean I don't see how RememberMeManager > interface can be used directly since it doesn't support > onLogin(PrincipalCollection subjectPrincipals) (because rememberme is > strictly limited to identity). Obviously I can hack Shiro anyway I > like (and believe me, I have) but don't you think that the design > dictates that in this case it'd be better just to implement a custom > SecurityManager that incorporates some aspects of RememberMeManager? > If not, how would you implement this using the RememberMeManager? 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? 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 a Map argument, much like the SessionFactory interface looks like now). Also, if you have to do any more 'hacking' :) and things aren't readily/easily available for you to override custom behavior, by all means please continue to post feedback here. I feel that's one of the most important things to achieve in the project (where possible of course and when the solutions are not rare edge-cases). Cheers, Les
