Re: Moving between security realms

[David Jencks]

On Tuesday, January 6, 2004, at 10:00 PM, Alan D. Cabrera wrote:

<snip>
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?
----
is there?
----


(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.
I think that we need the current subject in a static.  For example, my
implementation of getCallerPrincipal is:
public static Principal getCallerPrincipal() {
    Context context = (Context)
subjectContexts.get(currentCaller.get());
    assert context != null : "No registered context";
    return context.principal;
}
where currentCaller is a ThreadLocal object.  The call to
isCallerInRole() would work in a similar manner.  I'm not sure how this
would work if we stored the information in the EJB invocation object.
interface SecurityContext {
  Context getContext();
  void setContext(Context context);
  Subject getSubject();
  void setSubject(Subject subject);
}
extend EJBInstanceContext to either extend SecurityContext or have a 
getSecurityContext method.

change EJBContextImpl.EJBContextState to include EJBInstanceContext in 
the getCallerPrincipal and isCallerInRole methods, and use the security 
context in the obvious way to answer the questions.

With this kind of pattern you may still need one threadlocal somewhere, 
but you are likely to access it much less often.

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.
If I have the user/pw from one realm, how useful would the password be
in the target realm?  The only thing I can think of is a mapping a cert
to a cert who's expiration is no more than the original cert.
The connector spec mentions credential mapping but I don't really see a 
specific case there.  However, the very simple case I mentioned 
requires the Subject to have the original login password available, so 
it can be used to log into the database.

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.
Neat idea.  I think it should go in o.a.g.security for now, until the
number of patterns get really large.
OK, I'll try this out.
thanks
david

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:-)
You better get crackin'  :p
Regards,
Alan