JaccAuthorizationRealm constructs WebRoleRefPermission objects at runtime with an incorrect role value by populating the actions of the permission with the value of the role-link element instead of the value of the role-name element.

The WebPermissionMapping class correctly adds WebRoleRefPermission objects to the JACC provider at deploy time by constructing the WebRoleRefPermission objects with actions equal to the value of the role-name element, per section 3.1.3.2 of the JACC spec.

The issue appears at runtime when the JACC provider's Policy.implies method is called with a WebRoleRefPermission that has actions equal to the value of the role-link element. Section 4.1.3 of the JACC spec states that actions should be equal to the roleName. This behavior causes the JACC provider to return false because the handling of the role is not consistent.

The source of the issue is in the way that the JaccAuthorizationRealm relies on the value of the role that is passed to it by the org.apache.catalina.connector.Request class. The Request class translates the role-name into the role-link value before calling the realm. Here's the snippet of code from the Request class:

public boolean isUserInRole(String role) {

// Have we got an authenticated principal at all?
if (userPrincipal == null)
return (false);

// Identify the Realm we will use for checking role assignmenets
if (context == null)
return (false);
Realm realm = context.getRealm();
if (realm == null)
return (false);

// Check for a role alias defined in a <security-role-ref> element
if (wrapper != null) {
String realRole = wrapper.findSecurityReference(role);
if ((realRole != null) &&
realm.hasRole(userPrincipal, realRole)) /*** the realm is getting passed the real role (the role link)
return (true);
...

The JaccAuthorizationRealm class then takes this value and constructs the WebRoleRefPermission with it as follows:

public boolean hasRole(Principal principal, String name)
{
String servletName = (String) activeRequest.get();
WebRoleRefPermission perm = new WebRoleRefPermission(servletName, name);
...

An easy solution would be to change the WebPermissionMapping to set the actions to be the value of the role-link element, so that at least the handling of the role reference will be consistent across both deployment and runtime. However, doing this would violate the JACC spec.

The tougher solution is to have the JaccAuthorizationRealm translate the role-link back into the role-name before constructing the WebRoleRefPermission object.

Another solution would be to change the Request class, but that would require a change inside of Tomcat.