6 Replies Latest reply on Feb 22, 2007 7:29 PM by Scott Stark

    JBoss 4.2 related discussion

    Anil Saldanha Master

      Topic: Support deployment level principal-role mapping via jboss.xml.

      If there is deployment level principal-role mapping done by the user, we should be able to take this into account during authorization decisions.

      Here is an example of this mapping:

      <jboss>
       <assembly-descriptor>
       <security-role>
       <role-name>Administrator</role-name>
       <principal-name>j2ee</principal-name>
       </security-role>
       <security-role>
       <role-name>Employee</role-name>
       <principal-name>javajoe</principal-name>
       <principal-name>j2ee</principal-name>
       </security-role>
       </assembly-descriptor>
      </jboss>
      


      This info is available in the metadata and can be obtained in the JBossSX layer.

      The previous approach of "DeploymentRolesLoginModule" was unaccepted.
      http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg65476.html

      Any ideas about solving this properly?

        • 1. Re: JBoss 4.2 related discussion
          Scott Stark Master

          We just need to support the introduction of static roles. Where authentication is done to obtain a Subject, a post authentication interceptor can be added to optionally associated deployment level roles + mappings. This interceptor would have to be in between the authentication and authorization interceptors.

          In the web container, the construction of the JBossGenericPrincipal roles needs to consult the deployment metadata.

          • 2. Re: JBoss 4.2 related discussion
            Anil Saldanha Master

             

            "scott.stark@jboss.org" wrote:
            We just need to support the introduction of static roles. Where authentication is done to obtain a Subject, a post authentication interceptor can be added to optionally associated deployment level roles + mappings. This interceptor would have to be in between the authentication and authorization interceptors.

            In the web container, the construction of the JBossGenericPrincipal roles needs to consult the deployment metadata.


            That made perfect sense. Thanks Scott.

            • 3. Re: JBoss 4.2 related discussion
              Anil Saldanha Master

              An issue that I did not originally think of, is the subject after authentication is read-only. Cannot do much about adding roles into the subject.

              The PolicyContext getContextSubject is creating a read-only subject in the SubjectPolicyContextHandler

              theSubject = new Subject(true, principalsSet,
               activeSubject.getPublicCredentials(),
               activeSubject.getPrivateCredentials());
              


              I can probably use the SecurityAssociation.getSubject in the intermediate interceptor such that during authorization, the getContextSubject can return the read-only subject.

              • 4. Re: JBoss 4.2 related discussion
                Scott Stark Master

                The PolicyContext would just be a copy even if it was not read-only. One way would be to simply add the roles to the invocation and update the authorization interceptor logic to look there in addition to the RealmMapping.doesUserHaveRole call. Not having the roles assigned to the Subject is the direction we are heading anyway.

                • 5. Re: JBoss 4.2 related discussion
                  Anil Saldanha Master

                  There is no need to add the roles to the invocation. The principal to role mapping can be obtained via the org.jboss.metadata.AssemblyDescriptorMetaData principal to role mapping, which is available on the container passing into the interceptor.

                  For 5.0, this is not an issue as we can use role mapping logic before authorization in the build up of the security context.