Understanding UserInRole for JACC

[anil.saldhana]

This is in reference to http://jira.jboss.com/jira/browse/JBAS-3054

/** Servlet 2.4 Specification: SRV.12.3
 If no security-role-ref element matching a security-role element has been declared, the container must default to checking the role-name element
 argument against the list of security-role elements for the web application. The isUserInRole method references the list to determine whether the
 caller is mapped to a security role. */

In the non-jacc version, a hasRole check happens in the RealmBase with the GenericPrincipal (X,Z) when a call is made for isUserInRole("X"), but with the JACC version, the WebRoleRefPermission for role "X" is not available just with the metaData constructed from the web.xml and jboss-web.xml because the roles assigned to the user are in the GenericPrincipal and not available until we make a check. Plus the web.xml does not define any security-role-ref elements. This means that the call isUserInRole("X") will fail even though it should be true.

[anil.saldhana]

The doubt is that the roles to the caller are "X" and "Z" and are obtained by the JAAS authentication and get populated into the JBossGenericPrincipal.

But the way, JBoss JACC works is that it constructs all the permissions from the metaData (obtained from the DD). Hence the assigned roles for the caller are not available via permissions.

What is the best way to handle this?

One solution is that in the hasRole method of the JaccAuthorizationRealm, we need to construct the jacc permissions for the roles placed in the generic principal and updated in the policyconfiguration.

Scott, what are your thoughts on this problem?

[anil.saldhana]

Trying to understand what is the spec specified behavior for programmatic security in J2EE, in the absence of "security-role-ref" elements specified in the DD.

Does it mean, isUserInRole and isCallerInRole
a) succeed for roles the user has (obtained currently via Jaas auth)?
- In this case, the roles are not available to be setup as perms until the need for a check of isXXXInRole.
b) succeed for roles defined in the DD (web.xml and ejb-jar.xml) and nothing else?
- Available from the metaData.


Based on this, we will have to rework the UserInRoleUnitTestCase as well as the associated EAR.

[starksm64]

For JACC there has to be a security-role-ref and/or a security-role in the web.xml descriptor. There is no other standard way to get a permission into the policy configuration.

[starksm64]

The only extension we could add to make the jacc/non-jacc equivalent would be to treat roles found associated with the subject that do not have a role-link from an existing security-role-ref as implicit security-role values. For now I would say that jacc tests require a fully specified descriptor as the tck could check that a policy does not have more permissions that are specified in the descriptor.

[anil.saldhana]

So essentially this means that the call,

boolean valid = isUserInRole("X") will pass in a non-jacc version whereas in the Jacc version, it will be false for the following web.xml

<security-constraint>
 <web-resource-collection>
 <web-resource-name>JBAS-3043</web-resource-name>
 <description>no description</description>
 <url-pattern>/*</url-pattern>
 </web-resource-collection>
 <auth-constraint>
 <role-name>Z</role-name>
 </auth-constraint>.....
 </security-constraint>

 <security-role>
 <role-name>Z</role-name>
 </security-role>

In the non-jacc version, the role check happens based on the roles populated in the GenericPrincipal, whereas in the jacc version, the role checks happen based on the roles obtained from the DD, being populated into the PolicyConfiguration.

Thanks for the clarification, Scott.

[anil.saldhana]

My question was:

What this basically means is that the programmatic security checks for isXXXInRole is dependent on
the authorization provider (non-jacc or jacc) for the results to be returned.

Scott replied with:

That is only true for an underspecified deployment descriptor. If its fully specified the results
are the same.

[anil.saldhana]

The only extension we could add to make the jacc/non-jacc equivalent would be to treat roles found associated with the subject that do not have a role-link from an existing security-role-ref as implicit security-role values. For now I would say that jacc tests require a fully specified descriptor as the tck could check that a policy does not have more permissions that are specified in the descriptor.

We basically should mandate completely specified deployment descriptors for programmatic security to work. For additional roles populated in the subject, it is just a value added feature that is supported by the non-jacc provider.


A short term problem that I see is the current testcase UserInRoleUnitTestCase that should be appropriately retrofitted to handle both underspecified/fully-specified web.xml for both the non-jacc/jacc providers on the background.

[anil.saldhana]

Scott has pointed out some guidance provided by the jacc specification with regard to handling unmapped JSPs.

B.19 Calling isUserInRole from JSP not mapped to a Servlet
Checking a WebRoleRefPermission requires the name of a Servlet to
identify the scope of the reference to role translation. The name of a scoping servlet has not been established for an unmapped JSP.

Resolution- For every security role in the web application add a
WebRoleRefPermission to the corresponding role. The name of all such
permissions shall be the empty string, and the actions of each
permission shall be the corresponding role name. When checking a WebRoleRefPermission from a JSP not mapped to a servlet, use a permission with the empty string as its name and with the argument to isUserInRole as its actions. This specification will require that containers implement this resolution when the Servlet Specification requires that containers test the caller for membership in the role named by the
argument to isUserInRole when isUserInRole is called from an unmapped
JSP.


So it seems like we need to map the jsp servlet name to a blank name and fix our permission mapping to add a blank permission name.