You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Jencks <da...@yahoo.com> on 2007/07/01 23:12:42 UTC
Thoughts on Authentication
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
Re: Thoughts on Authentication
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Thoughts on Authentication
Posted by David Jencks <da...@yahoo.com>.
On Jul 2, 2007, at 1:59 PM, David Blevins wrote:
>
> On Jul 2, 2007, at 10:22 AM, David Blevins wrote:
>
>> 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.
>
> To answer my own question... looks like nothing. It was in the
> JSRs "optional" section and doesn't seem to be mentioned in the spec.
We could write something, but it would be back-end specific. jaspi
doesn't necessarily use JAAS or login modules etc, so a jaspi
provider can definitely be store specific and include extra
functionality like this. Or maybe we could use the jpam stuff?
thanks
david jencks
>
> Oh well :|
>
> -David
>
>
Re: Thoughts on Authentication
Posted by David Blevins <da...@visi.com>.
On Jul 2, 2007, at 10:22 AM, David Blevins wrote:
> 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.
To answer my own question... looks like nothing. It was in the JSRs
"optional" section and doesn't seem to be mentioned in the spec.
Oh well :|
-David
Re: Thoughts on Authentication
Posted by David Blevins <da...@visi.com>.
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
>
>