Hi Kalle, 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. Shiro makes this artificial, strong separation between rememberme and > authentication. In the javadocs for RememberMeAuthenticationToken > ( > http://jsecurity.org/api/org/jsecurity/authc/RememberMeAuthenticationToken.html > ) > it is said that "Authentication is the process of proving you are who > you say you are". It is stated that rememberme is not considered an > authentication and implied that only using username/password can be > used for an "actual authentication". 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. When you are only remembered, you haven't authenticated anything. By the very definition of authentication, there can be no confusion as to whether or not a simply 'remembered' user is authenticated or not. Any framework that does not make this distinction is just plain wrong, and the amazon.comexample shows a very real use case of why this is important. Shiro makes no requirement that passwords are used to authenticate, and they have no relationship to rememberMe functionality at all - users can authenticate by whatever means they desire, such as public/private key pairs. The RememberMeAuthenticationToken and its parent interface explicitly have no notions of usernames and/or passwords for this reason. > However, in practice there's no > way to know that whoever supplied the password is who they say they > are and passwords are generally not considered the strongest form of > authentication. Shiro's default rememberme implementation results in > no or very weak authentication, The correct statement is "Shiro's default rememberMe implementation results in no authentication" - on purpose. And again, Shiro's default rememberMe implementation makes no assumptions about whether or not passwords are good enough - the application configuration does. When you are remembered, by default, you are not automatically authenticated - and never should considered as such just by the very definition of the word. Indeed, because Shiro does not retain credentials in rememberMe, it _can't_ automatically authenticate the remembered user (a good thing). The application developer decides what state is 'good enough' for his application by performing the appropriate checks, and because Shiro distinguisihes between the different states, the developer can do this easily. It is not something cludged together as an afterthought in the framework. That is, currentSubject.isAuthenticated() == true: provided correct credentials during the current session currentSubject.getPrincipal() != null: provided correct credentials during the current session OR during a previous session and they are currently 'remembered' from a previous session currentSubject.getPrincipal() == null: anonymous user - hasn't authenticated yet and is not rememebered. > but there are alternatives that > results in stronger form of key-based authentication. Private/public > keys are often considered equally strong authentication to > username/password and for remember me, using rolling tokens (as > described for example at > > 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. Also, when a user logs out - the rememberMe cookie is invalidated. The article's approach and Shiro's approach are _very_ similar. > 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. 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? Best, Les
