geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Resolved: (GERONIMO-415) Improve on Subject.doAs for client invoking secure EJB
Date Thu, 09 Jun 2005 06:52:16 GMT
     [ ]
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:
>      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:
For more information on JIRA, see:

View raw message