> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]
> 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
