Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Tue, 6 Jan 2004 21:42:07 -0800
Subject: Re: Moving between security realms
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: David Jencks <david@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <FF7CE36846E01B439945B55FFB1DF5BE1437@customer.panix.com>
Message-Id: <3AC7D3E1-40D4-11D8-8F72-003065F4889C@coredevelopers.net>


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

>
>
>> -----Original Message-----
>> From: David Jencks [mailto:david@coredevelopers.net]
>> 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
>