David Jencks resolved GERONIMO-415:
Fix Version: 1.0-M4
Rev 189719. Supply a CallbackHandler in your dd or plan, and a realm-name in the plan. When you start your app you will be logged on, and the entire app client run in Subject.doAs.
The geronimo login gives the client a stripped down Subject with, mostly, an identification principal. Ejb calls using the openejb protocol include the id from this identification principal and use it to look up the already-logged-in fully populated server side subject.
I think this addresses what you asked for, but please add more details if there is more.
> It would be nice to provide a replacement or alternative means of invoking secure EJBs.
> 1) Subject.doAs is kind of unwieldy if your EJB calls are scattered across your application (such as a Swing app with different EJB calls for every screen controller, separate save and load calls, etc.). Every one needs to be wrapped by a PrivilegedAction, and all Exceptions are reduced to type java.lang.Exception and so on. This is a particular problem for existing application that don't have that wrapping already, so there would be significant code changes required to use Geronimo EJBs (as things stand).
> 2) Subject.doAs is, to quote a wise man, "sloooooooooooooooowwwww".
> It would be nice to have some authentication method that authenticated you on the server side and returned some token to indicate who you are (could be a Subject, could be some encrypted thingy, whatever). Then on the client side we could stuff your authentication token in a ThreadLocal or something, and let you just cheerfully call any EJBs without any particular wrapping. But in our EJB client stubs, we could fetch the token out of the ThreadLocal and pass it to the server, which could back out your proper Principals whenever you try to access a secure resource. This would be effectively invisible to the client, other than the initial login, which would be very advantageous.