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 22:31:41 -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: <FF7CE36846E01B439945B55FFB1DF5BEF6B7@customer.panix.com>
Message-Id: <27C62935-40DB-11D8-8F72-003065F4889C@coredevelopers.net>


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
>
>