Jeffery,
Ken asked that I check to see if all of your questions have been answered.
it looks you make have 2 outstanding questions:
1. it appears RolesAllowed is letting through users who shouldn't have access.
you can see the effective policy for your application by looking in domains/domain1/generated/policy/<your application><your ejb jar>/granted.policy
you should see one or more grants of an EJBMethodPermission corresponding to the getAssetList method. The policy file was generated by the deployment system when your app was deployed and its content defines the behavior of the policy subsystem wrt to your application. In other words, if you were to show us that file, we could tell you who the system believes should be allowed to call the various methods of your application.
2. You asked Is there an easy way to show which roles a user has?
In EE, roles are logical privileges that are mapped at deployment time to specific sets of users. The role-references used in calls tol isCallerInRole are mapped at deployment time to the set of user identities mapped to the logical roles mapped to the embedded references. The mappings of references to roles, and of roles to environment specific identities serve to ensure that the logical privilege model of the application can be bound to the specific environment in which it is deployed (i.e., in support of wora).
So the perhaps not so obvious answer to your question, is that roles do not survive deployment. they are replaced by the application specific and component scoped role references (which under default circumstances map 1-to-1 in name to the names of the logical roles). An application that knows all the declared role (references) can call isCallerInRole with each; whch I believe will provide the answer you are looking for.
moreover, In a post J2EE 1.3 EJB container that is operating in the standard mode of using JSR 115 for authroization (as is Glassfish) your application can directly query java.security.Poilcy to determine all the referenced roles to which the caller is a member (in the scope of a particular componet/EJB)
To do this, you would call Policy.getPermissions(ProtectionDomain pD) with a pD constructed with a null CodeSource and with the principal(s) of the caller. GetPermissions will return a Permissions object, from which you could extract all the EJBRoleRefPermissions (granted to the caller) with name (obtained via getName()) corresponding to the EJB in whose context you wish to determine the granted role references. On each resulting EJBRoleRefPermission, you could obtain the corresponding roleRef, by calling getActions on the permission.
Unfortunately there is a potability/performance tradeoff with using Policy in this fashion, in that you need to construct the protection domain with all the principals of the caller (as found in its Subject) not just the caller Principal. All containers are required to set the caller Subject such that it available via:
Subject.getSubject(AccessController.getContext());
but a container is only required to set the subject when it is running with a SecurityManager. When a container runs without a SecurityManager, it generally performs better, but the caller Subject must be obtained via a proprietary API (in Glassfish via SecurityContext.getSubject).
Ron
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=218418