geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <>
Subject [jira] Updated: (GERONIMO-415) Improve on Subject.doAs for client invoking secure EJB
Date Fri, 05 Nov 2004 19:26:32 GMT
     [ ]

Aaron Mulder updated GERONIMO-415:

    Component: application client

> Improve on Subject.doAs for client invoking secure EJB
> ------------------------------------------------------
>          Key: GERONIMO-415
>          URL:
>      Project: Apache Geronimo
>         Type: Improvement
>   Components: OpenEJB, application client
>     Versions: 1.0-M2
>     Reporter: Aaron Mulder

> 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:
If you want more information on JIRA, or have a bug to report see:

View raw message