You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geronimo.apache.org by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org> on 2004/11/05 20:26:32 UTC

[jira] Updated: (GERONIMO-415) Improve on Subject.doAs for client invoking secure EJB

     [ http://nagoya.apache.org/jira/browse/GERONIMO-415?page=history ]

Aaron Mulder updated GERONIMO-415:
----------------------------------

    Component: application client

> Improve on Subject.doAs for client invoking secure EJB
> ------------------------------------------------------
>
>          Key: GERONIMO-415
>          URL: http://nagoya.apache.org/jira/browse/GERONIMO-415
>      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:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira