Hi, Am 27.03.2012 um 10:40 schrieb David G.:
> Is it customary for a Sling Auth Handler's extractCredentials(..) method to > be responsible for > > 1) validating human-supplied credentials (username, password) > 2) and issuing a authentication token (ex. a secure auth Cookie) The extractCredentials method does neither of those tasks. That method just extracts the credentials from the request and created an AuthenticationInfo object which is later used by the Sling Authenticator to authenticate against the repository. When authenticationis successfull, the (optional) authenticationSucceeded method is called at which time any auth cookie can be created. This method is defined by the AuthenticationFeedbackHandler interface. If you AuthenticationHandler implements this interface it is called back. Please refer to http://sling.apache.org/site/authentication.html for full details. > > My understanding was a Auth Handler merely authenticates credentials, and > generally doesnt actively issue tokens. > > An example flow might be: > > 1) User POSTs username/password to servlet. There is no servlet involved in the authentication process (other than for providing the HTML form for the user to enter user name and password). > 2) Servlet authenticates credentials (via whatever means necessary, may > need to reach out to 3rd party system) > 3) Servlet adds a secure auth cookie to response object > 4) Servlet redirects to resource /page/b.html > 5) Authentication Handler matches on /page/b, extracts the secure auth > cookie, validates, and "logs" the user in for that request What's happening is: 1. client sends request with username and password 2. SlingAuthenticator calls AuthenticationHandler 3. AuthenticationHandler returns AuthenticationInfo with username and password 4. SlingAuthenticator calls RepositoryFactory with AuthenticationInfo to get resource resolver and validate the credentials 5. SlingAuthenticator calls AuthenticationFeedbackHandler.authenticationSucceeded which may set cookies 6. request continues to be processed (or is redirected) In subsequent requests, the AuthenticationHandler will in step 2 create an AuthenticationInfo from the cookie which has been set in step 5. But the rest of the processing will remain the same. Important is, that this all takes place before any servlet is ever hit. Hope this helps. Regards Felix > > This makes sense to me, but > org.apache.sling.commons.auth.Authenticator.login(request, response) seems > to imply they can/should be used to authenticate requests that come in as > unauthenticated, and the servlet then issues an auth request. I believe a > sample flow would be: > > 1) User POSTs username/password to servlet. > 2) Servlet authenticates credentials (via whatever means necessary, may > need to reach out to 3rd party system) > 3) Servlet adds a secure auth cookie to response object > *4) Servlet calls Authenticator.login(..)* > *5) Servlet then can perform actions as the new user (not-anonymous anymore) > *4) Servlet redirects to resource /page/b.html > 5) Authentication Handler matches on /page/b, extracts the secure auth > cookie, validates, and "logs" the user in for that request > > Should a Sling Auth Handler ever be used to handle Steps 2 and 3, > effectively having two Sling Auth Handlers: One to authenticate the human > supplied username/password and to issue a secure auth cookie, and Another > to authenticate the secure auth cookie on subsequent requests?
