[ http://issues.apache.org/jira/browse/GERONIMO-415?page=all ]
David Jencks resolved GERONIMO-415:
-----------------------------------
Fix Version: 1.0-M4
Resolution: Fixed
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.
> Improve on Subject.doAs for client invoking secure EJB
> ------------------------------------------------------
>
> Key: GERONIMO-415
> URL: http://issues.apache.org/jira/browse/GERONIMO-415
> Project: Geronimo
> Type: Improvement
> Components: application client, OpenEJB
> Versions: 1.0-M2
> Reporter: Aaron Mulder
> Assignee: David Jencks
> Fix For: 1.0-M4
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
