Hi, On 28.01.2010 09:17, Carsten Ziegeler wrote: > Hi, > > I think the new authentication bundle is a great step forward. However > :) I think we should enhance it a little bit to support cookie/session > based authentication. > > For basic auth everything works fine as user/password are send on each > request by design. > > With cookie/session based authentication you usually have a form which > you use to authenticate once and then you get some kind of an id - this > can be a session id or some id in a cookie identifying you. Whenever the > server receives this id it verifies that the id has not been hijacked > and by looking at the id does the authentication for this request. > Currently this is done by an authentication handler and to properly do > this, it requires the authentication handler to store the user and > password somewhere - either in the cookie, the session, the repository, > in memory etc. Regardless of where the password is stored, it is imho > bad practice to store the password at all. > > When the authentication handler receives the id and has successfully > performed the hijacking check, the handler knows from which user the > request is comming and that this user has already successfully > authenticated. > > So what about adding something like a trusted credentials object which > is added to the authentication info in this case. This credentials > object contains just the user.
I was thinking along the very same lines while looking at the authentication handlers from SLING-1116. My solution would be: The handler stores a special Credentials object into the AuthenticationInfo object. This is then used by the SlingAuthenticator to login. The handler also provides a LoginModulePlugin to accept these special credentials and verify the identity towards the repository. Of course, the Credentials implementation is private to the login handler bundle and thus is reasonable safe to not be abused. > > The trusted credentials object can be used by the Authenticator to do > whatever is appropriate to authenticate this user. > > Now, this solution seems a little bit unsecure to me as the > authentication handler can just create a trusted credentials with the > user. So we could secure this a little bit more by using the feedback > mechanism. If the first request is authenticated by the Authenticator > successfully, it calls the feedback handler and could provide some key > which the authentication handler has to put into the trusted credentials > for this user on further requests. Obivously this key should not be the > password :) So this would mean, that we would have to keep two stores per user logged in: A store in the Authenticator to be able to verify the "keys" and a store in the AuthenticationHandler to be able to provide the key (well the AuthenticationHandler will have a store anyway to be able to validate the client request). Regards Felix
