This is not something that is well handled by the policy providers bundled with glassfish,
but if you require such functionality, you could enhance either of the existing providers (or write your own) such that it does the type of processing you are looking for, whenever it is asked to check an EJBRoleRefPermission or a WebRoleRefPermission.
if you are willing to live with the assumption that your dynamic roles are mapped only to principals in the same name group, then you could enhance either of the providers to determine isUser/CallerInRole, for dynamic roles, by checking for the corresponding group principals in the
principals of the access control context. I would suggest that you only use this device to determine isUser/CallerInRole for roles that where not declared at deployment time.
check out the in-memory jacc provider under:
/v3/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/
given that you can assume a canonical p2r mapping for the undeclared roles, you should be able to enhance
private int doImplies(ProtectionDomain d, Permission p)
throws PolicyContextException {
to determine whether or not an EJBRoleRefPermission or WebRoleRefPermission for an undeclared roles should be granted (i.e., when the user/caller has the corresponding group principal)
It would be better if you could also enhance
private PermissionCollection getPermissions(PermissionCollection basePerms,
PermissionCollection domainPerms, Principal[] principals)
throws PolicyContextException, UnsupportedOperationException {
but in order to return the proper role permissions in the granted collection, you will need to determine all the ejb and servlet names defined for you app (whihc will be a little complicated)
since isUser/IsCallerInRole calsl doImplies, enhancing only doImplies may be sufficient.
for your purpose.
Ron
ps: You can determine the names of all EJBS and Servlets in your app, by modifying your provider such that you can find all the EJBRoleRefPermission and WebRoleRefPermissions, and extract the corresponding list of EJB and Servlet names used in these permissions.
also, you can configure an alternative jacc provider (in domain.xml), by setting a specific value for the jacc attribute of the security-service element. The value of this attribute must be the name of a jacc-provider sub-element of the security-service element. The default value of the attribute is "deafult", which matches the name of the file based jacc-provider. Setting the value of this attribute to "simple", for example, will cause the in-memory provider to be used, by the appserver.
[Message sent by forum member 'monzillo' (ronald.monzillo_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=378681