I've been starting to look into JASPI (Java Authentication Service
Provider Interface, http://jcp.org/en/jsr/detail?id=196 ) and also
trying to figure out how to remove the convoluted remote login code
in geronimo and am starting to think that I might have an idea how to
do both. Note that my understanding of JASPI might not be complete :-)
JASPI has two halves, the client side and the server side. Depending
on what you are doing, you might only be using one, e.g. for a web
app you aren't likely to have a client side since it's a browser not
a java program. I think its more or less a generalization of the
Authenticator interfaces servlet containers typically use.
On either side you supply a layer id and an application id and get an
authentication provider for that combination.
For a message/response cycle the sequence of events goes something
like this:
1. (client) Client asks the client authConfig to stuff some info into
the request message.
2. (server) server asks the server authConfig to authenticate based
on the request message. There are a bunch of complicated scenarios,
but in a simple case you are now authenticated.
--server processes the message and gets ready to return a response
3. (server) server asks the server authConfig to stuff some info into
the reply message
4. (client) client asks the client authConfig to validate the
response message based on the info from the server.
The functions of the client and server side authentication configs
seem to me to be very similar to the openejb IdentityResolver and
SecurityService interfaces
I think we can use this to eliminate the need for mysterious remote
login yet provide for "sessions" so we don't need to log in for each
request. My thinking is heavily influenced by what's going on in the
geronimo-openejb integration right now, so it might not correspond
quite as well to current openejb standalone. Here's my idea:
1. On the first request, the client figures out what identity and
credentials to use for the session and adds them to the request
message. For instance this could be username and password.
2. The server sees the credentials in the request and logs in. It
generates a token to identify the "session". In geronimo this is
currently stored in an IdentificationPrincipal in the Subject.
3. the server includes the token in the reply message
4. the client extracts the token from the reply message and saves it
with the caller's security information. For instance it could put it
in the private credentials of the user's subject.
5. On subsequent calls the client includes the token in the request
message rather than including the credentials.
6. When the server sees the token in the request message it locates
the appropriate security context (such as the Subject from the first
login).
To make this work in openejb I think we need more or less 2 changes:
1. IdentityResolver and SecurityService need to be more jaspi-
friendly. I think this means that we need "processResponse" type
methods, and both these and the existing "processRequest" type
methods need to include the layer and applicationId parameters. I'm
still wondering what the exact meaning of layer and appId might best
be, but at the moment I think that having the layer identify the
transport in some way and the appId identify either the ejbmodule or
the ejb itself would work. In the geronimo corba-openejb
implementation you can specify separate security policies for each
ejb and (I think and hope) transport. Also in JACC each ejb gets a
separate PolicyContextId so I think that having appId == ejbId would
be most appropriate.
2. The response object needs to include some security information,
just as the request object does.
------------------
I've been experimenting in geronimo with a little bit of this: I am
sending the credentials on each request and logging in for each
request, and this seems to be working fine. This avoids the
mysterious remote login but is presumably somewhat inefficient for
multiple calls since logging in generally takes some work. This does
require tracking a bit more information such as security realm name
so I'm starting to think that going directly for a jaspi or jaspi-
like implementation might make sense.
Comments? Comments on an appropriate timeframe?
thanks
david jencks
