geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject RE: Moving between security realms
Date Wed, 07 Jan 2004 13:22:31 GMT


> -----Original Message-----
> From: David Jencks [mailto:david@coredevelopers.net]
> Sent: Wednesday, January 07, 2004 1:32 AM
> 
> 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?
> ----

I'm moving my Geronimo code to Nova.  I'll check it in tonight.  For the
moment, you are correct in that the way to get this is
ContextManager.peekContext().getSubject(). 
 
> >>>
> >>>> (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.

Interesting.  I'll try to put this in.

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

How about a CallbackHandler, created by the LoginModuleWrapper, that
intercepts the credentials and places them in the subject,
RealmCredential(realmName, callback)? 


Regards,
Alan


Mime
View raw message