On Jul 1, 2007, at 2:12 PM, David Jencks wrote:
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).
This is similar to what OpenEJB does but the login always occurs
during application initialization either via an AppClient or a JNDI
initial context. Then when it comes to the request we have the
security token ready and waiting.
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.
Does JASPI require that the login happen during a normal request? I
don't think lazy authentication via a request is such a good idea as
it makes it difficult for the programmer to control the time when
authentication occurs. Anyway, if JASPI can be split into an acquire
the security token and pass the token phases, it should fit into the
current OpenEJB without any API modifications, which is important as
the APIs have a lot of history and changes could break existing clients.
-dain
