Declarative Security with Spring

SpringSecurity is a security framework based on the Spring Framework. It provides authentication and authorization for web and rich client applications. AndroMDA supports Spring declarative role based security for Spring Services.

Configuration

To enable Security support for the spring cartridge set serviceSecurity to true. All other Security properties have been defaulted.

The authentication has to be configured in a separate security context file. The following presents a small example, for more details have a look at the Spring Security reference. 

<beans>
    <bean id="myUserDetailsService" class="com.mycompany.MyUserDetailsServiceImpl">
        <!-- get access to the user entity -->
        <property name="userDao"><ref bean="userDao" /></property>
    </bean>

    <bean id="daoAuthenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
        <property name="userDetailsService">
            <ref bean="myUserDetailsService"/>
        </property>
    </bean>

    <bean id="authenticationManager" class="org.springframework.security.authentication.ProviderManager">
        <property name="providers">
            <list>
                <ref bean="daoAuthenticationProvider"/>
            </list>
        </property>
    </bean>
</beans>

To add this additional context file to your spring configuration (beanRefFactory) you can use the AndroMDA merge feature with adding the filename to <!-- beanRefFactory merge-point -->.

The spring cartridge will than generate all code into the applicationContext file.

Please note that if you previously used EJB security, you have to disable it by removing the property securityRealm from your AndroMDA build configuration. The nice thing is: you don't have to modify your modeling in this case, the Security support is based on the same notation as the EJB security support.

Modeling

Now you have to define some roles for your application. This is simply done by adding actors to your model named with the role's name. A role prefix, e.g. ROLE_ as proposed by Spring Security for the default serviceDecisionVoter implementation org.springframework.security.access.vote.RoleVoter, can be configured though the namespace property securityRolePrefix. This prefix is optional for the actor naming and will be automatically added to the generated code, if missing in the model (recommended).

howto/org/andromda/test/8/a/uml.gif

The next thing to do is to draw a dependency from a role actor to a <<Service>> or to one or more methods of the spring service. Making the whole service dependent on an actor grants the role access to all service operations. To grant access to single operation(s) draw the dependency from the actor to the operations(s).

howto/org/andromda/test/8/b/uml.gif

AndroMDA now generates a security interceptor with a list of all operations and its assigned roles to the applicationContext file. Each service call will then be intercepted by the serviceSecurityInterceptor. The default interceptor org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor only calls the service method implementation if it successfully authenticated the SecurityContext stored within the ContextHolder. More details on this behavior can be found in the Spring Security Reference.

  • Auto-generated source that does not need manual editing
  • Auto-generated source that should be edited manually
  • File that is affected by the modifications applied in this section