4 Replies Latest reply on Dec 9, 2008 1:29 PM by Anil Saldanha

    Security aspect updates

    Scott Stark Master

      In going through the current jboss-aspects/security aspects and applying them to the profileservice, I see a few issues we should work on updating to be better mc/pojo citizens.

      1. The jndi based dynamic security makes it a little awkward to setup a bean/interceptor that depends on an AuthenticationManager instance. We should create an AuthenticationManagerBean or some such that simplifies this. Right now you can do something like the following to create an instance that uses the security-jboss-beans.xml JNDIBasedSecurityManagement as a factory. The ProfileServiceAuthenticationManager bean can then be injected into the AuthenticationInterceptor:

       <bean name="ProfileServiceAuthenticationManager" class="org.jboss.security.AuthenticationManager">
       <constructor factoryMethod="getAuthenticationManager">
       <factory bean="JNDIBasedSecurityManagement"/>
       <parameter>profileservice</parameter>
       </constructor>
       </bean>
       <interceptor xmlns="urn:jboss:aop-beans:1.0" class="org.jboss.aspects.security.AuthenticationInterceptor">
       <constructor>
       <parameter><inject bean="ProfileServiceAuthenticationManager"/></parameter>
       </constructor>
       </interceptor>
      


      2. The RoleBasedAuthorizationInterceptor depends on the older RealmMapping interface, and nothing directly provides access to this. I was able to use the JNDIBasedSecurityManagement.getAuthorizationManager instance as a RealmMapping instance using:
       <bean name="ProfileServiceAuthorizationManager" class="org.jboss.security.AuthorizationManager">
       <constructor factoryMethod="getAuthorizationManager">
       <factory bean="JNDIBasedSecurityManagement"/>
       <parameter>profileservice</parameter>
       </constructor>
       </bean>
       <interceptor xmlns="urn:jboss:aop-beans:1.0" class="org.jboss.aspects.security.RoleBasedAuthorizationInterceptor">
       <constructor>
       <parameter><inject bean="ProfileServiceAuthenticationManager"/></parameter>
       <parameter><inject bean="ProfileServiceAuthorizationManager"/></parameter>
       </constructor>
       </interceptor>
      

      but this relies on the implementation details of the AuthorizationManager. We need a new RoleBasedAuthorizationInterceptor that uses the AuthorizationManager spi.

      3. All of the *InterceptorFactory rely on hard-coded lookups of metadata from the advisor metadata api with fallbacks to jndi lookups. Because of the mc capabilities with specifying how a bean is created, these are probably all obsolete, but we should review them.

      Generally we should just review what the current spis are and their associated beans and make sure the beans expose sufficient pojo based configuration, and that the aspects cover the use cases we want.