Re: Moving between security realms

[David Jencks]

On Wednesday, January 7, 2004, at 06:16 PM, Alan D. Cabrera wrote:

-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 1:00 PM
On Wednesday, January 7, 2004, at 05:22 AM, Alan D. Cabrera wrote:
<snip>
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().
I'm hoping this move is only for the most nova-ejb-specific parts of
the security framework?  I'd like to eventually have a similar level
of
security on mbean calls, and I think most of the framework could be
reused.
In particular, I would like Geronimo itself to have context frameworks
for transactions, target instances (such as the ejb instance object)
and security.  These can be used or extended by containers deployed in
Geronimo, such as Nova, Jetty, etc.
I'm a little confused.  If I keep the current Subject context in the
ContextManager, wouldn't that obviate the need to store the current
Subject in the EJBInstanceContext?
Never mind, I forgot how the model I was thinking of works.  Nova's 
TransactionContext relies on a ThreadLocal to keep track of the 
TransactionContext instance for the current thread, just like your 
ContextManager does for security.  For some reason I had thought the 
current TransactionContext was included in the Invocation object.

I'll be happy with the jca stuff if I can continue to get the current 
subject from the ContextManager.

<snip>
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)?
I don't understand what you have in mind here.  If the credential
supplied happens to be a password credential, a wrapping
CallbackHandler could find the PasswordCallback(s).  I have never seen
a certificate based login system, or Kerberos, but I'd imagine they
would use a custom Callback object that a generic wrapper could not
detect.  What am I missing?
Is there some reason not to have a LoginModule put the credentials
used
to authenticate into the Subject?  It looks to me as if the Subject at
least is designed to hold these credentials.  On the other hand, I
compared the JBoss login modules and they don't store the credentials
either.
Sorry, I was over engineering this.  I was thinking that the 
LoginModule
was a black box and wouldn't store the credential that we needed.  I 
was
being clever by using a CallbackHandler wrapper to "steal" credentials
and stuff them into the Subject.  Of course, if we wrote the module, it
could store the credentials in the Subject, which is a standard and
accepted practice for LoginModules to do.
Well, I don't think it will make a lot of difference:-)  I doubt many 
people will use caller identity, and they just wont be able to if they 
insist on using a login module that doesn't save the credential you 
logged in with.

thanks
david

Regards,
Alan