Hi Felix - thanks for the info. have a few more Qs inline. On Tue, Mar 27, 2012 at 11:18 AM, Felix Meschberger <[email protected]>wrote:
> 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. > > This makes sense and is inline w my understanding. Thanks for the info on the authenticationSucceeded() > > > 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) The Login Form has to POST to *something* .. what does it point at? > > 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 > So there you could have 2 auth handlers: 1 whose extractCreds looks for POST params username/password and 2nd who looks for the existance of a Cookie. Or optionally combine them into a single AuthHandler. 3. AuthenticationHandler returns AuthenticationInfo with username and > password 4. SlingAuthenticator calls RepositoryFactory with AuthenticationInfo to > get resource resolver and validate the credentials > If you want to do something "special" during validation (such as reach out to a 3rd party system and check some state or send to a registration page if the username doesnt exist in the user list) -- where would this come into play? > 5. SlingAuthenticator calls > AuthenticationFeedbackHandler.authenticationSucceeded which may set cookies > 6. request continues to be processed (or is redirected) > Where/when/why would Authenticator.login(request, response) get called. This seems to be be a mechanism to be called from a servlet (or someplace other than the sling auth "ecosystem") > 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. > Yup - makes perfect sense. > > Important is, that this all takes place before any servlet is ever hit. > Yup. > 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? > >
