On Tue, Jun 16, 2009 at 6:50 AM, Les Hazlewood<[email protected]> wrote: > I think your comments are based on maybe previous Acegi use and there is > possible confusion as to the differences between the two projects. > First and foremost, Shiro's rememberMe cookie does not store credentials > (passwords, keys, etc). It can never be used to find a user's password. > Only identity (principals), such as a username, is stored. Premises #2 and > #3 in your linked article on rolling tokens does not apply to Shiro.
Yes, not confused really, just asking for confirmation. > It is most certainly not artificial. Authentication is the act of verifying > who you are who you say you are by supplying credentials that verify your > identity - the type of credentials (password, public/private key pair, etc) > are irrelevant and up to what the system architect/administrator deems as > appropriate. Sure, but it depends on your viewpoint. Shiro takes the approach that remember should not supply any credentials, but I see it as a line where different authentication/identifying mechanisms could supply some credentials that vary in their strength. >> http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/) >> makes remembering the identity a much more secure process. > I just read that article, and I fail to see how it is any better than > Shiro's default approach. Those cookies are valid for only a current > session, just as Shiro's 'authenticated' state is only valid for a single > session. In fact, Premises #1, #2, and #3 are exactly why our > implementation functions the way it does! :) And because we don't store > passwords in the rememberMe cookie, Premises #2 and #3 aren't even valid for > Shiro. Oh I think you need to re-read the article until you see the difference and agree that its at least stronger form of identification than Shiro's default approach :) It's stronger because the server issues you a key that is good for one time access only. Compare this to Shiro - you are only storing the identity on the client side and the server didn't issue you any key to compare to. It is also stronger because all of the rolling tokens can be invalidated on the server, for example when you successfully use username/password authentication or change a password on the server. Finally, it's stronger because the server decides if the remembered identity is expired - not the client. > Also, when a user logs out - the rememberMe cookie is invalidated. The > article's approach and Shiro's approach are _very_ similar. I don't want to make this yes/no argument, but if you claim that I don't think you fully understood the article. >> I wonder if it would make more sense >> to implement a custom RememberMeManager or a custom authentication >> filter for it. Current implementation doesn't allow you to authorize >> the principal for anything when rememberMe is used, > I'm confused by this statement. If you are 'remembered' with Shiro, you can > most certainly be authorized (remembered user X is allowed/not allowed to do > action y). Authorization is based solely on identity (which is retained by > rememberMe) - not based on your authentication state. Ok, so it's clear that Shiro's rememberme is only to used for remembering the identity. Let's forget about the rememberme for now and I'll rephrase the problem: how do I best implement authentication logic based on disposable server issued keys so that client doesn't have to go through a particular authentication point? > Based on what I've read in that article, Shiro already does what you > require. I'm wondering if this is just confusion based on Acegi-related > preconceptions? Certainly not. Acegi doesn't take any stand on how strong any particular authentication/identification mechanism is - it's all left up to the developer. Shiro instead implements custom logic for rememberme, i.e. just for the "remember my identity only" case. Kalle
