On 12.4.2012 18:51, Darran Lofthouse wrote:
Just been having a look at the Security Module page and had a couple
of comments related to experiences in JBoss AS - Pete suggested I post
my comments over here.
A few of problems we have had historically in JBoss AS releases
regarding the authentication at the transport level are: -
- The assumption that everything has a username and a credential.
- That authentication takes a single step.
- That the duration an authentication is valid for can be pre-defined.
+1
What I was thinking about, is to have object AuthenticationContext,
which will encapsulate whole state of current user authentication
including credentials, tokens and other things (Username, password,
value of RememberMe cookie, SSO tokens, initialURI to redirect after
authentication...). Point of this object is to wrap all authentication
related data like credentials, urls, tokens etc. and store them between
various HTTP redirects, which are usually needed for some kinds of
authentication.
Second thing may be to have something like set of authentication
interceptors, where each interceptor can be used to deal with some
aspect of authentication. API can look like this
public interface AuthenticationInterceptor
{
public void invoke(HttpServletRequest request, HttpServletResponse
response, AuthenticationContext context);
}
Examples of interceptors:
- RememberMeInterceptor to deal with RememberMe cookie,
- UsernamePasswordInterceptor, which will redirect user to login
screen if his credentials are not already found in AuthenticationContext
(classic username/password usecase)
- OpenSSOInterceptor, which will redirect user to OpenSSO (or other
SSO server) if OpenSSO ticket not found, or it will perform validation
of SSO ticket if OpenSSO ticket is found
These interceptors will use Authenticators, which are already mentioned
on wiki page
https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts
(Like RememberMeInterceptor will use RememberMeAuthenticator etc.)
USE CASE EXAMPLE:
Let's imagine that user is interested in authentication through SSO
server like OpenSSO
In this case we have interceptors like:
Request 1: User will send request to secure uri:
http://localhost:8080/app/secure
- LoginRequiredInterceptor will recognize that it's private URI and
set AuthenticationContext.setLoginRequired(true)
- OpenSSOInterceptor will try to find SSO token (in OpenSSO, it's
saved in cookie iplanetDirectoryPro). Token not found, so calling
redirection to OpenSSO console.
Request 2: User submits his credentials in OpenSSO console and OpenSSO
redirects user back to his application with SSO token set:
http://localhost:8080/app/verifyssologin
- OpenSSOInterceptor will find SSO token in request. It will save
it into AuthenticationContext and then call
OpenSSOAuthenticator.authenticate(authenticationContext)
- OpenSSOAuthenticator will use OpenSSO agent to do verification of
SSO token by communicating with OpenSSO server. It will return
AuthenticationStatus.SUCCESS and save it into AuthenticationContext if
SSO token verification is successful
Looking at the initial API I just wonder is it also starting to follow
the same assumptions. Picking username / password authentication as a
first step whilst it may be simple historically has led us into
situations where adding more complex scenarios end up being added as a
workaround.
I suppose the real question is where would this be used, is this
something that would only be used within apps that want to establish
some form of 'security context' with an identity or could this also be
used in other locations such as valves implementing http
authentication. If the former than maybe not a huge issue but if the
latter this API could be repeating the problems of the past.
Regards,
Darran Lofthouse.
