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. 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 :) WDYT? Carsten -- Carsten Ziegeler [email protected]
