> > > 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.
That's Shiro's _default_ assumption. Any developer can change this if they want to ;) Which is obviously what you're asking. I just wanted to be very clear to most readers and users of the framework that auto-login - where the end-user is automatically logged in without their required interaction, is usually a really, really bad idea. It is not something that should be done by default (and is why we don't do it by default). That being said, Shiro is definitely flexible and will allow you to override almost anything you want. If one wants to shoot themselves in the foot, then they're free to do so (I'm not implying you're doing this, I'm just making a point that the framework is not inherently limited to only the case of "remember only my identity" - that's just the default approach for the same exact reasons your article points out and is sufficient for 95% of use cases). > >> > 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. My point was this doesn't matter much if the programmer uses Shiro's API properly. If the API is being used correctly, it would protect certain site areas depending on their state (anonymous, remembered, and/or authenticated). This, ultimately, is the end-goal of the article to which you linked and what is important. Yes, the random ID does give the server a little more control over the entire process, but it is mostly unnecessary when using the API correctly. For example, the developer should do something like this: if ( currentSubject.isAuthenticated() ) { spendUsersMoney(); } and never this: if ( currentSubject.getPrincipal() != null ) { spendUsersMoney(); } There are JSP tags that execute the same logic based on these 3 states: anonymous, a user (either remembered or authenticated), and authenticated, respectively: <shiro:guest/> <shiro:user/> <shiro:authenticated/> There are tags that represent the inverse of these as well. But if you disagree that this doesn't provide the same end-goal as what the article advocates, albeit in a different way, I'd certainly like to hear your thoughts on why - if there is something that can be added to the framework to make lives easier for people, it probably should be incorporated :) Ok, so it's clear that Shiro's rememberme is only to used for > remembering the identity. That's the default yes - but not limited to that. The developer can do whatever he likes by implementing the RememberMeManager interface. You're probably a super user in this regard and know exactly how you want things to work - its just I think people should ask themselves if the above approach is not usable before going down that road - most of the time it is not necessary and could even cause a security hole. It is typically a bad thing to perform sensitive operations without explicitly requiring human interaction to verify identity, so we don't enable this by default on purpose. 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. Same with Shiro - we just provide a nice default that works assuming you use the API correctly. The developer can certainly override this if they desire by providing their own RememberMeManager implementation. Please let us know if you have any questions about your implementation or any other ideas that might make RememberMe better. I for one am definitely open to suggestions! Cheers, Les
