Re: Moving between security realms

[David Jencks]

On Tuesday, January 6, 2004, at 08:48 PM, Alan D. Cabrera wrote:

-----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.
Not yet committed?   Is there anywhere to get the current subject from?

(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);
I was thinking more along the lines of  the TransactionContext idea in 
Nova to avoid thread locals.  The "environment", what ever that might 
be, would supply something implementing
setContext(Subject, AccessControlContext)//maybe split up into 2 calls
getSubject()
getAccessControlContext()

The EJB invocation object could implement this, and other things could 
also as necessary.

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.
Well, to make what I'm saying concrete, if you want to log into the db 
using the same user/pw as you logged into the app with, you need the 
password you logged into the app with to be available.  Right now it's 
not saved in the Subject filled in by either example LoginModule.  I 
think they should be.

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.
Having two interfaces/objects is a much better idea.  The MCF instance 
has to be included in  the PasswordCredential that the resource adapter 
expects.

     //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) {
}
How about calling this interface RealmBridge?  Do you think it deserves 
a package of its own, maybe o.a.g.security.bridge?  With this model  
the mappings aren't specific to resource adapters, so I'd be happy to 
put them in the security module.
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.
So in your model the BridgeBean and/or the CallbackHandler do the 
mapping?  Indeed, that provides a better separation of concerns.  I've 
been slightly confused because the login modules/ realms I've been 
thinking of just fill in a subject, they don't actually talk to the EIS 
to validate them.  Having the mapping outside of the realm certainly 
allows for other realms/login modules that actually do something.

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.
I haven't looked at that part yet:-)
thanks
david

Regards,
Alan