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 caller.
-------------------------- 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 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 subject
CallbackHandler callbackHandler = new SubjectUserPasswordCallbackHandler(contextSubject);
Subject returnedSubject = new Subject();
LoginContext loginContext = new LoginContext(this.realm, returnedSubject, callbackHandler);
loginContext.login();
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
