What is the equivalent of security-role-ref and role-link in Spring Security 3.0?

2
votes

I'm porting a standard web-app with a web.xml, security-constraint(s), security-role(s), and login-config to Spring Security 3.0. I've found the equivalent mappings for nearly all of the functionality in the web.xml except for the security-role-ref element.

I don't want to dictate the security role names are for the deployment environment so I'm leveraging the mapping feature of J2EE security to map logical role names to physical role names like so:

<servlet>
    <servlet-name>MyServlet</servlet-name>
    <servlet-class>org.example.MyServlet</servlet-class>
    <security-role-ref>
        <role-name>MANAGER</role-name>
        <role-link>DISTRICT_MANAGER</role-link>
    </security-role-ref>
</servlet>

Note in the snippet above, there are one or more checks in code or JSP's to see if the user is in the logical role "MANAGER". In this particular deployment, that role is linked to the physical role "DISTRICT_MANAGER" which is returned from the JAAS context (JDBC or LDAP).

Is there a similar mapping facility in Spring Security 3.0? I'm hoping to avoid having to modify the application to check for the physical roles of the deployment environment and I'm not in a position to have the sys admins add specific roles/permissions to user's LDAP records just for my application.

Thanks in advance.

1
javaspringjakarta-eespring-security

1 Answers

1
votes

Spring Security 3.1 has a general mapping strategy called GrantedAuthoritiesMapper which you can implement and inject into an AuthenticationProvider to tell it how to convert the authorities it loads into those which will be used to make decisions within the application.

If you are using an earlier version, you can just implement AuthenticationProvider directly and customize the creation of the Authentication object yourself. As an example, you could define a set of mappings defined as a map in your application context file and use those to create the final set of authorities returned from the provider. The mapping has then really just moved from web.xml to the app context file (and should be less verbose).