-
1. Re: Understanding UserInRole for JACC
anil.saldhana Apr 20, 2006 2:10 PM (in response to 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? -
2. Re: Understanding UserInRole for JACC
anil.saldhana Apr 20, 2006 11:53 PM (in response to 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. -
3. Re: Understanding UserInRole for JACC
starksm64 Apr 21, 2006 10:03 AM (in response to anil.saldhana)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.
-
4. Re: Understanding UserInRole for JACC
starksm64 Apr 21, 2006 10:11 AM (in response to 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.
-
5. Re: Understanding UserInRole for JACC
anil.saldhana Apr 21, 2006 10:11 AM (in response to 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. -
6. Re: Understanding UserInRole for JACC
anil.saldhana Apr 21, 2006 10:16 AM (in response to 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.
-
7. Re: Understanding UserInRole for JACC
anil.saldhana Apr 21, 2006 11:50 AM (in response to anil.saldhana)"scott.stark@jboss.org" wrote:
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. -
8. Re: Understanding UserInRole for JACC
anil.saldhana Apr 21, 2006 6:02 PM (in response to 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.