geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: How is app client to ejb security supposed to work?
Date Sat, 07 Apr 2007 19:22:46 GMT

On Apr 7, 2007, at 10:14 AM, David Jencks wrote:

> I can't figure out how javaee app client to ejb security is  
> supposed to work (and I have some evidence it isn't).
>
> What I'd expect is that:
>
> - you log into the app client, resulting in a Subject in the  
> ContextManager.  This subject would have to include a private  
> credential that stores the password.
> - when you call an ejb, the ejb client code consults the  
> ContextManager to see if there's a subject, and if so looks for a  
> private credential and if present gets the client identity from  
> openejb and uses it in the call.  It could stash the client  
> identity in the subject so it didn't have to log in again.
>
> What (if anything) is currently implemented?  If nothing is, and  
> the above looks plausible, where does this hook up to openejb, and  
> what would I have to implement/modify?

That's about right.  All of it should work.  To fill in some detail:

The app client container performs a login over the jaas/rmi protocol  
stuff and gets a subject.
The subject contains one principal as you say.  This principal is  
essientially a token that the ContextManager understands.
The app client container then does a doAs with the subject when  
invoking the app client's main class.
On all ejb calls the app client makes openejb will find the Subject  
in the access control context, pull out the principal and send that  
with the request performed on the openejb ejb protocol.  This act  
requires the configurable strategy for determining the app client  
identity to be set to "geronimo" and the geronimo security jar  
present in the app client class path (that jar contains the strategy,  
IIRC, might be in the app client jar).

On the server side upon receiving a request, the EjbRequestHandler  
will call the SecurityService.associate(object) method and pass in  
the object that the client gave as the identity; in this case, the  
principal object created eariler.  This is where the ContextManager  
gets the principal back and then finds the related subject and pushes  
it onto the thread.  If the object is null or there is no relating  
subject, the default subject can be used (can't recall if that's in  
or not).

 From there all code should work normally.  The  
GeronimoThreadContextListener should push and pop on the  
ContextManager at each context change as well as make the required  
JACC calls to set the JACC ContextID.

All that code is there, and the ejb 2.1 security section was very  
green at one point -- i was pretty tired so I'm only 80% sure on that.

Hope this helps.

-David


Mime
View raw message