if you are running in a jacc environment, and the security manager is enabled, and the component is configured to runAs its caller, then you can call Subject.getSubject(), within the EJB and get the subject corresponding to its caller.
When the security manager is disabled, jacc relaxed the requirement to set the subject in the accessControlContext (for performance reasons). If you cannot accomodate running with the security manager enabled, another possible way to ensure that the subject is available to the EJB, could be to develop your own jacc policy provider, and to have it establish the proper access control context (after obtaining the subject via the jacc subject policy context handler).
Once the caller subject can be acquired within your EJB, you can either interogate it directly looking for Group principals (mapped to roles) assigned to the caller, or you could call getPermissions to determine all the EJBRoleRefPermission and/or WebRoleRefPermission granted to the caller.
I'll try to post some details on how to do this.
-----
we could also consider adding a getDeclaredRoles method to the EJB and Servlet apis; although it would help if you can describe how the application would know how to handle roles that it didn't know about at the time it was developed?
Ron
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=293584