8 Replies Latest reply on Apr 21, 2006 6:02 PM by Anil Saldanha

    Understanding UserInRole for JACC

    Anil Saldanha Master

      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.





        • 1. Re: Understanding UserInRole for JACC
          Anil Saldanha Master

          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 Saldanha Master

            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
              Scott Stark Master

              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
                Scott Stark Master

                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 Saldanha Master

                  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 Saldanha Master

                    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 Saldanha Master

                       

                      "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 Saldanha Master

                        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.