geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Moving between security realms
Date Wed, 07 Jan 2004 03:44:16 GMT
I'm working to finish up the outbound connector architecture security 
implementation and there are a few things I'm not quite clear on and 
think may have wider relevance.  I think the best way to view the 
situation is as a login to one security realm from another that the 
user is already authenticated in.

In the outbound connector framework, using container managed security, 
the ConnectionManager (part of the app server, not the resource 
adapter) is responsible for providing a Subject containing a single 
"Resource Principal" (the use of which I have not yet discerned) and 
the credential for logging into the remote EIS (such as a database).  
For the standard user/password type of db login, this credential is a 
PasswordCredential holding the user name and password needed to log in, 
and the ManagedConnectionFactory instance used to create the 
connection.  The connector spec indicates this Subject should be 
generated through use of JAAS LoginModules.  The LoginModule can either 
actually authenticate the credentials itself or simply create a Subject 
with some credentials and rely on the EIS to do the actual 
authentication.  This Subject is then passed to the resource adapter to 
use in creating a new connection, matching existing connections, or 
reauthenticating an existing connection.

I think a similar scheme may be appropriate for generating credentials 
for calling ejbs in a different server.  There may also be other uses 
for such a scheme.

Anyway, lets consider how the contents of the new Subject can be 
derived.  Basically, they can be regarded as mapped from the security 
context of the realm the calling application is operating in.  There 
are several choices for this mapping:

1. "Configured Identity".  No matter who the caller is, you always get 
the same resource principal and credentials (user/pw).

2. "Caller Impersonation".  The resource principal is the same as the 
caller, and the credentials are the same as the caller.  For instance, 
the username/password you log into the app with are those used to log 
your connections into the database.

3. Principal and Credential Mapping.  Some algorithm is used (such as 
looking up in some kind of table or map or service) to find the 
principal and credentials for the constructed Subject from those of the 

Implementation proposal/notes

It's necessary to get the "previous" security info.  I think the way to 
do this is from the previously logged in Subject.  It appears this is 
available from ContextManager.peekContext().getSubject().  At the 
moment I don't see any reason or possibility to push the generated 
Subject on the stack in ContextManager (for instance, there is no 
access control context AFAIK).  (Also, in the future, it may prove 
better to include the Subject and AccessControlContext in a generalized 
InvocationContext object.)

It will also be necessary to include the authentication info used to 
authenticate the Subject in the Subject as credentials.  It appears 
this is left out of the current example login modules. I'm assuming 
this is an oversight.

I propose an interface ConnectorRealm to be implemented by 
SecurityRealms used by container managed security for connectors.  It 
will have two methods:

     //used to specify the ManagedConnectionFactory used in 
PasswordCredentials, and as an mbean endpoint.
     void setManagedConnectionFactory(ManagedConnectionFactory 
     //used to "login" and get the Subject for the connector
     Subject getSubject();

getSubject will typically look like this:

Subject getSubject() {
   Subject contextSubject = ContextManager.peekContext().getSubject();
   //this callback handler extracts user/password from the supplied 
   CallbackHandler callbackHandler = new 
   Subject returnedSubject = new Subject();
   LoginContext loginContext = new LoginContext(this.realm, 
returnedSubject, callbackHandler);
   return returnedSubject;

The LoginModule can cooperate with this Realm to map the principal and 
credentials as necessary.

Presumably the realm can cache the contextSubject to returnedSubject 
map to speed up calls.

I'd really appreciate comments on this.

As mentioned before, I think a similar process could be appropriate for 
determining who the caller is and what their credentials are when 
calling from one ejb application to another, especially from one server 
to another.

Many thanks,
david jencks

View raw message