> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 2004 10:44 PM
>
> 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
> 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).
I agree and got rid of it.
> (Also, in the future, it may prove
> better to include the Subject and AccessControlContext in a
generalized
> InvocationContext object.)
Nice idea. Something like?
ContextManager.setContext(subject, key, value);
ContextManager.setCaller(subject);
Object value = ContextManager.getContext(key);
> 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 had always thought that the credentials that were mentioned in
credential mapping would be something generated by the LoginModule, e.g.
certs. I think that these are saved in the Subject.
> 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);
I'm not sure what ManagedConnectionFactory and PasswordCredentials have
to do with this example.
> //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.
I was thinking of something very, very, similar but I was thinking of a
new Bridge Bean:
Subject mapSubject(Subject subject) {
}
I was trying to shy away from having the SecurityRealm do all things for
all situations. Also, a mapping may be very specific between two types
of realms. I don't think it's a good idea to put all that nxm mapping
information in a security realm. I was thinking, what if I don't have
access to the code for a Security realm, e.g. from a 3rd party vendor, I
could use my Bridge Bean to do the mapping.
> 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.
I was thinking the same thing. Maybe it could be used for the CORBA
interoperability part of the ejb spec also.
Regards,
Alan
