On 27 Oct 2009, at 22:25, D. Stuart Freeman wrote:
On Tue, Oct 27, 2009 at 08:52:49PM +0000, Ian Boston wrote:
The doc at [1] is good. The main thing to remember is the OSGi
HttpService calls handleSecurity on the HttpContext registered
against the URL. In the case of Sling, the SlingMainServlet
implements HttpContext.handleSecurity that calls the
SlingAuthenticator which then selects an AuthenticationHandler and
calls authenticate.
I've looked over that doc a couple times and this all seems to make
sense, though I feel like I'm missing a bit of context to really
understand the ramifications.
All AuthenticationHandler.authenticate is supposed to do is to
inspect the request (cookies, URL, request parameters, post
parameters), to extract any information it can and build a set of
Credentials.
This is in line with my expectations.
These Credentials might represent an anonymous user if the request
has no tokens that represent a user, or the user in question.
So AuthenticationHandler.authenticate just creates
AuthenticationInfo from the request, it does not ask the client for
anything more.
Also as I expected.
---------------------------------------
If Sling decides that the the user must login, it will call
requestAuthentication. The AuthenticationHandler implementation
should for requests that it controls, respond with a response that
causes the client to perform authentication and return true.
How does Sling decide that the user must log in? Does it have
anything
to do with the result of a call to authenticate()?
I am not certain about that, I think it might be as a result of the
application rather than Sling, although sling does call the
AuthenticationHandler.requestAuthenticaiton when the
SlingAuthentication.login method is called.
Internally this as a result of either anon users not allowed into the
instance or the credentials supplied are not allowed to login to the
Repository or if there are too many logins active. (have a look at the
SlingAuthenticator.login(...),
SlingAuthenticator.handleLoginFailure(...) and the things that call it.
AFAICT Triggering the AuthenticationHandler.requestAuthenticaiton
method does not happen inside the Sling Engine, so this would be
something that an application would make happen. (or perhapse we need
something else in sling)
eg
a permission denied exception *and* an anon session would cause the
AuthenticationHandler.requestAuthenticaiton to be invoked.
Ian
So in the case of a WebISO system (CAS/WebAuth/etc) it would craft a
redirect to a URL that performs authentication on the central WebISO
server. When the client comes back with the authentication payload
the AuthenticationHandler.authenticate method should pick the
authentication payload off the request, and set something to store
the fact the user authenticated.
OK, I had missed that this needs to set up it's own means of retaining
the fact that the user is authenticated, thinking the browser session
would be enough.
There are good and bad options here, for instance a secure self
transforming cookie would be a good choice, a session cookie would
be an ok other than a server side Http session. The
AuthencationHandler.authenticate should also look for this cookie or
session to extract the credentials.
Noted.
-----------------------------------------
Triggering authentication.
1. just go to the WebISO url with a suitable return location (as
every return url passes through the
AuthenticationHandler.authenticate)
This makes sense.
2. do something on the request that forces the redirect to happen.
I think this is what I'm looking for. Do I set a request parameter?
What looks for the parameter? I think this relates to my earlier
question of how Sling decides I need to log in.
above :) ?
Did any of that make sense ?
Things are a little less hazy, and it's good to know I'm on the right
track.
Ian
1 http://sling.apache.org/site/authentication.html
On 27 Oct 2009, at 20:16, D. Stuart Freeman wrote:
I'm trying to write an AuthenticationHandler for CAS, I've looked
at the
OpenID handler to get an idea of how this should work. It looks
like
authenticate() gets called for every request and if it can't
authenticate
the user then requestAuthentication() gets called to prompt a
login. I
can't figure out though how to trigger the call to
requestAuthentication(), if authenticate() returns null I just get
dropped on the page I was trying to navigate to and returning
uthenticationInfo.DOING_AUTH gives me a 401 error. Am I
misunderstanding
the way AuthenticationHandlers work?
If it's any help in understanding what I'm doing wrong the basic
logic of
my handler is as follows. authenticate() checks the session to
see if
the user is already logged in, if not it tries to do a CAS gatewayed
auth. If neither of those is successful it returns null.
requestAuthentication() redirects the user to the CAS login page and
returns true.
--
D. Stuart Freeman
Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
