> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 07, 2004 12:42 AM
>
> 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.
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.
> >> 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.
> >> 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.
> > 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
