The following technique is supported by all JACC compatible containers given that they are configured
with a typical Policy provider capable of returning a PermissionCollection encapsulating all the
WebRoleRefPermission and/or EJBRoleRefPermission objects pertaining to a ProtectionDomain.
Within the scope of a called Servlet or EJB that is configured to run as its caller,
invoke the "Container Subject Policy Context Handler" to obtain a Subject containing the
principals of the caller. Note that the handler will return null if the caller identity
has not been established.
private static final String SUBJECT_HANDLER_KEY =
"javax.security.auth.Subject.container";
Subject s = (Subject) PolicyContext.getContext(SUBJECT_HANDLER_KEY);
Extract the principals of the caller from the Subject, and use the 4 argument ProtectionDomain
constructor to construct a ProtectionDOmain for the caller of the component. If the Subject is null,
use a zero-length Principal array to construct the ProtectionDomain.
CodeSource cs = new CodeSource(null, (java.security.cert.Certificate[]) null);
Principal principals[] = (s == null ? new Principal[0] : s.getPrincipals().toArray(new Principal[0]));
ProtectionDomain pd = new ProtectionDomain(cs, null, null, principals);
Get the Policy object of the JRE, and call policy.getPermissions() with the ProtectionDomain as argument.
The returned PermissionCollection will include all the Permissions granted to the caller; including those (i.e., EJBRoleRefPermission(s) and WebRoleRefPermission(s)) indicating role memberships. Depending on the
underlying Policy implementation, the returned collection may contain "unresolved" permissions which will need to be
resolved in order to be detectable by the selection logic in the next step. Force resolution by calling implies on the collection with an argument permission of the desired type (i.e. a WebRoleRefPermission or an EJBRoleRefPermission).
Policy policy = Policy.getPolicy();
PermissionCollection pc = policy.getPermissions(pd);
pc.implies(new WebRoleRefPermission(null, null));
Iterate over the permissions and select the WebRoleRefPermissions or EJBRoleRefPermissions
granted to the caller. Each such permission indicates that the caller is a member of
a role (identified by the actions of the permission) in the context of the named Servlet or EJB as
(identified by the name of the permission). Select only those Permissions corresponding to the type of the
component (Servlet or EJB) in which the roles of the caller are being determined.
Return an array of String values containing the the set of all unique action values for which
HttpServlet.isUserInRole(action) or EJBContext.isCallerInRole(action) returns true.
The following sample demonstrates the role computation in the context of a named Servlet. The analogous
computation is performed in the context of a named EJB, by substituting EJBRoleRefPermission for WebRoleRefPermission,
and EJBContext.isCallerInRole for HttpServletRequest.isUSerInRole.
HashSet roleSet = null;
HttpServletRequest request; //assign to current request
Enumeration e = pc.elements();
while (e.hasMoreElements()) {
Permission p = e.nextElement();
if (p instanceof WebRoleRefPermission) {
String roleRef = p.getActions();
if (roleSet == null) {
roleSet = new HashSet();
}
//confirm roleRef via isUserInRole to ensure proper scoping to Servlet Name
if (!roleSet.contains(roleRef) && request.isUserInRole(roleRef)) {
roleSet.add(p.getActions());
}
}
}
if (roleSet != null) {
return roleSet.toArray(new String[0]);
}
return new String[0];
Note that the returned values will correspond to role reference values; which are values that may be used by the
application to test role membership. These values may differ from the names of application roles if the application has defined security-role-ref elements. If no security-role-ref elements have been defined, the role reference values will correspond exactly to the names of the application roles.
When running with a SecurityManager enabled, the calling code must be granted permission to call the PolicyContext.getContext and the Policy.getPolicy methods. This can be facilitated by encapsulating these protected methods in a doPrivileged, and by loading this utility code within a CodeBase for which the necessary permissions can be conveniently granted. For Glassfish, this can be done by packaging the utility in its own jar and placing the
jar in glassfish/lib.
Posted by monzillo
@ 02:34 PM EDT
[
Comments [1]
]
![[This is a Roller site]](http://blogs.sun.com/monzillo/resource/images/roller-logo.gif){kind=logo}
Thanks. Just what I needed.
Posted by Remy Monsen on February 16, 2009 at 06:43 PM EST #