Still reading the JASPI docs, haven't gotten to the bulk of your
email yet. One think that pricked my ears when reading the JSR page:
"The J2EE programming model does not define standard APIs that may be
used to cause container visible user accounts to be created from the
portable component programming model."
I've been complaining about that one for years! "J2EE apps are
portable! Oh? Wait. You want to write an app where people can sign
up online then log in and use your app?? No, you definitely can't do
that in a portable way... good thing people never write online apps
like that."
Can't wait to see what the spec does to fix this.
While I'm reading, do you know of any implementations of providers
out there?
-David
On Jul 1, 2007, at 2:12 PM, David Jencks wrote:
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
