1 2 Previous Next 15 Replies Latest reply: Nov 17, 2010 6:46 AM by Martin Borgman RSS

Mapping Application Roles to Declarative Role

Anil Saldhana Master

Many users would like to map the application roles that are derived out of the Jaas authentication process to declarative roles (defined in various deployment descriptors like web.xml).

There is a feature request that has been implemented with an optional login module called as the RoleMappingLoginModule.
http://jira.jboss.com/jira/browse/JBAS-3323

This works perfectly fine for majority of the cases except for one, when there are login modules with the control flag of "Sufficient" and no "required/requisite" modules. The problem is that the optional RoleMapping LM will never be reached, if authentication succeeds.

Given this, there are alternatives:
1) The user can override the getRoleSets method of any JBoss standard LM.
2) The Abstract Server LM base class can be retroffited with role mapping logic.

Both the options hold merit in various usecases. Option 2 can solve majority of the user needs, but the issue is that we cannot tie the logic to a single store for role map, like the properties file as done by the RoleMappingLoginModule. This can require a override in all LM if users need to do it.

The right solution is logic should be added after the Jaas authentication process is completed. This will decouple the process from the login module life cycle. The above discussion holds true mainly for JBoss 4.0.x

As I see, I think we will need to add the logic into the JaasSecurityManager. The question is should we get the rolemapping setup for a particular security domain, by peeking into the jaas configuration. I welcome your thoughts on this topic.

For JBoss 5.x, the Security SPI as discussed in the following forum thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81097
will handle the Role Mapping logic.

  • 1. Re: Mapping Application Roles to Declarative Role
    chris griffith Expert

    Anil,

    Although this does not answer your question...

    Consider the current case where a developer of a j2ee component references some other component. This is done by name, correct? Then the deployer is resonsible for mapping between the application used name and the deployment environment name. So my point is that I would see this as a deployment issue with a need to modify to the ejb-jar.xml and web.xml descriptors. Of course that may not be possible.

    If it can be seen that this is a deployment issue, and if web.xml or ejb-jar.xml do not cover these issues, then I would think that the jboss.xml file would need to contain this mapping.

    Am I way off base? cgriffith

  • 2. Re: Mapping Application Roles to Declarative Role
    Anil Saldhana Master

     

    "j2ee_junkie" wrote:

    If it can be seen that this is a deployment issue, and if web.xml or ejb-jar.xml do not cover these issues, then I would think that the jboss.xml file would need to contain this mapping.


    Cannot include the mapping in the jboss DD because it will be like tying the mapping to a layer(web/ejb) when it should be at the security domain level for multple layers.

  • 3. Re: Mapping Application Roles to Declarative Role
    chris griffith Expert

    I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml

    <assembly-descriptor>
     <security-role>
     <role-name>
     <principal-name>
     </security-role>
    </assembly-descriptor>
    


    This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role?

    cgriffith

  • 4. Re: Mapping Application Roles to Declarative Role
    Sohil Shah Master

    Since it makes sense to associate this mapping at the security-domain level to be utilized at different layers of the app (not just ejb and web)(I am thinking Portal,SEAM, JBPM etc)

    wouldn't it make sense to extend the configuration options in the login-config.xml so that you can specify the role/identity mappings kind of like this:


    <application-policy name="security-domain-name">

    <login-module>blahblah</login-module>

    <role-mapping>

    <application-role>whatever role from login module</application-role>
    <deployment-role>whatever deployment role it should map to</deployment-role>

    </role-mapping>
    </application-policy>

    Ofcourse this is just an example, and definitely needs better element names

  • 5. Re: Mapping Application Roles to Declarative Role
    Anil Saldhana Master

     

    "j2ee_junkie" wrote:
    I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml

    <assembly-descriptor>
     <security-role>
     <role-name>
     <principal-name>
     </security-role>
    </assembly-descriptor>
    


    This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role?

    cgriffith


    Agreed. This is how WL/WebSphere do it. I still think it may be wise to put it at the security domain level via an external configuration.

  • 6. Re: Mapping Application Roles to Declarative Role
    Anil Saldhana Master

     

    "sohil.shah@jboss.com" wrote:
    Since it makes sense to associate this mapping at the security-domain level to be utilized at different layers of the app (not just ejb and web)(I am thinking Portal,SEAM, JBPM etc)

    wouldn't it make sense to extend the configuration options in the login-config.xml so that you can specify the role/identity mappings kind of like this:

    <policy>
    <application-policy name="security-domain-name">
    <authentication>
    <login-module>blahblah</login-module>
    </authentication>
    <role-mapping>
    <role>
    <application-role>whatever role from login module</application-role>
    <deployment-role>whatever deployment role it should map to</deployment-role>
    </role>
    </role-mapping>
    </application-policy>

    Ofcourse this is just an example, and definitely needs better element names



    Close. The RoleMappingLoginModule uses a properties file to specify the mapping.
    http://wiki.jboss.org/wiki/Wiki.jsp?page=RoleMappingLoginModule

  • 7. Re: Mapping Application Roles to Declarative Role
    Sohil Shah Master

     

    "anil.saldhana@jboss.com" wrote:

    Close. The RoleMappingLoginModule uses a properties file to specify the mapping.
    http://wiki.jboss.org/wiki/Wiki.jsp?page=RoleMappingLoginModule


    Right but the issue with using it this way with association with the LoginModule is that the LoginModule may not fire in 100% of usecases, as indicated.

    Looks like we kind of need a way to specify the role-mapping independent of the LoginModule, so that the roles are populated without dependence on particular LoginModule

  • 8. Re: Mapping Application Roles to Declarative Role
    Scott Stark Master

     

    "sohil.shah@jboss.com" wrote:

    Right but the issue with using it this way with association with the LoginModule is that the LoginModule may not fire in 100% of usecases, as indicated.

    Looks like we kind of need a way to specify the role-mapping independent of the LoginModule, so that the roles are populated without dependence on particular LoginModule


    Correct. We need a separate authorization aspect(s) that can be applied to the authentication result to build up the authorization context independent of the authentication phase. Its a legacy overloaded usage of jaas that the login modules provide the declarative roles.

  • 9. Re: Mapping Application Roles to Declarative Role
    chris griffith Expert

    Scott,

    Its a legacy overloaded usage of jaas that the login modules provide the declarative roles.


    Are you saying that Login Modules really should just authenticate, and not authenticate and authorize?

    cgriffith

  • 10. Re: Mapping Application Roles to Declarative Role
    Scott Stark Master

    Yes. This is already the case when you use the JACC provider, at least an implementation other than the current jboss default.

  • 11. Re: Mapping Application Roles to Declarative Role
    Sohil Shah Master

     

    "j2ee_junkie" wrote:

    Are you saying that Login Modules really should just authenticate, and not authenticate and authorize?


    Seems like the issue being addressed is who populates the Subject with role information (LoginModule or an Authorization aspect).

    Decoupling this function from the LoginModule makes perfect sense.


    The LoginModule does not do the actual *authorization enforcement*. That function is actually performed by the different layers in the application like (web,EJB,JACC,some XACL module etc)

  • 12. Re: Mapping Application Roles to Declarative Role
    Scott Stark Master

     

    "sohil.shah@jboss.com" wrote:
    "j2ee_junkie" wrote:

    Are you saying that Login Modules really should just authenticate, and not authenticate and authorize?


    Seems like the issue being addressed is who populates the Subject with role information (LoginModule or an Authorization aspect).

    Decoupling this function from the LoginModule makes perfect sense.


    The LoginModule does not do the actual *authorization enforcement*. That function is actually performed by the different layers in the application like (web,EJB,JACC,some XACL module etc)


    Yes, and instead of just a Subject representing the security context, we should have a security context that contains a Subject, trust domain info, authorization info/pointers, etc to allow better integratin/reuse of authorization aspects.


  • 13. Re: Mapping Application Roles to Declarative Role
    chris griffith Expert

    Dear gang,

    Well after a good night's rest (something of a rarety these days with my 3mo old son) and a shot of coffee, the light bulb over the head finally turned on. I am reluctant to admit that it was not until then that I really understood the problem purposed and all of your suggestions.

    That said, I would like to point out that the RealmMapping interface was designed to be a point of access for Principal to Role mapping. As such there needs to be a way to configure this mapping for the RealmMapping implementor to store and use. As Scott pointed out, currently this is a "legacy overloaded use of JAAS". I now understand and agree. Also, Scott has pointed out the benefits of creating a security context that can store this mapping, among other things. This is good, but it still does not explain how to configure the mapping. For that, I seem to agree with Anil and Sohil. The JaasSecurityManager as a RealmMapping should have a way to configure the mapping other than thru the use of the JAAS login. The login config then seems to be the logical place to be extended to provide a per security domain mapping.

    Another idea that comes to mind is to create a new AuthenticationManager and RealmMapping class (for this discussion I will call it NewSecurityManager) that performs JAAS login to obtain identity (like JaasSecurityManager), but does not depend on Roles to be assigned to Subject. The login will just assign Principals to the Subject as JAAS intended.

    Then a pluggable means to configure the mapping from Principals to Application Role could be created. Such pluggins could contact a persistent store (db, ldap, file) or be configured dynamically. The pluggin used would be a NewSecurityManager config parameter.

    Just my updated thoughts. enjoy, cgriffith

  • 14. Re: Mapping Application Roles to Declarative Role
    Anil Saldhana Master

     

    "scott.stark@jboss.org" wrote:

    Yes, and instead of just a Subject representing the security context, we should have a security context that contains a Subject, trust domain info, authorization info/pointers, etc to allow better integratin/reuse of authorization aspects.


    We can do the security context clean up in the time frame of JBoss 5.0.0.GA (50%) or 5.0.1 (100%).

    I am wondering how difficult will it be for those users who have customized JBoss security or have had deeper integration, because keeping the overloaded subject with the roles/calleridentity/runasidentity logic after the cleanup, for backward compatibility, will be a nightmare in terms of manageability/complexity.

1 2 Previous Next