Component Authorization Using Spring Security

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

This page describes how you can configure method-level authorization using Spring Security on your components so that users with different roles can only invoke certain methods.

Securing Flow Components

To secure MethodInvocations, you must add a properly configured MethodSecurityInterceptor into the application context. The beans requiring security are chained into the interceptor. This chaining is accomplished using Spring’s ProxyFactoryBean or BeanNameAutoProxyCreator. Alternatively, Spring Security provides a MethodDefinitionSourceAdvisor, which you can use with Spring’s DefaultAdvisorAutoProxyCreator to automatically chain the security interceptor in front of any beans defined against the MethodSecurityInterceptor.

In addition to the daoAuthenticationProvider and inMemoryDaoImpl beans (see Configuring Security), the following beans must be configured:

  • MethodSecurityInterceptor

  • AuthenticationManager

  • AccessDecisionManager

  • AutoProxyCreator

  • RoleVoter

The MethodSecurityInterceptor

The MethodSecurityInterceptor is configured with a reference to the following:

  • AuthenticationManager

  • AccessDecisionManager

Following is a security interceptor for intercepting calls made to the methods of a component myComponent, which defines two methods: delete and writeSomething. Roles are set on these methods as seen below in the property securityMetadataSource.

<beans xmlns="http://www.springframework.org/schema/beans"
  <bean id="myComponentSecurity" class="org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor">
    <property name="authenticationManager" ref="authenticationManager"/>
    <property name="accessDecisionManager" ref="accessDecisionManager"/>
    <property name="securityMetadataSource">

Note: Because of a limitation in Spring, you must refer to the component implementation and not the interfaces it implements when defining the security bean.

The AuthenticationManager

This bean is responsible for passing requests through a chain of AuthenticationProvider objects.

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

The AccessDecisionManager

This bean specifies that a user can access the protected methods if they have any one of the roles specified in the securityMetadataSource.

<bean id="accessDecisionManager" class='org.springframework.security.access.vote.AffirmativeBased'>
      <property name="decisionVoters">
                  <ref bean="roleVoter"/>

The AutoProxyCreator

This bean defines a proxy for the protected bean. When an application asks Spring for a myComponent bean, it will get this proxy instead.

<bean id="autoProxyCreator" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="interceptorNames">
    <property name="beanNames">
    <property name='proxyTargetClass' value="true"/>

When using BeanNameAutoProxyCreator to create the required proxy for security, the configuration must contain the property proxyTargetClass set to true. Otherwise, the method passed to MethodSecurityInterceptor.invoke is the proxy’s caller, not the proxy’s target.

The RoleVoter

The RoleVoter class will vote if any ConfigAttribute begins with ROLE_. The RoleVoter is case sensitive on comparisons as well as the ROLE_ prefix.

  • It will vote to grant access if there is a GrantedAuthority, which returns a String representation (via the getAuthority() method) exactly equal to one or more ConfigAttribute objects starting with ROLE.

  • If there is no exact match of any ConfigAttribute starting with ROLE_, the RoleVoter will vote to deny access.

  • If no ConfigAttribute begins with ROLE_, the voter will abstain.

<bean id="roleVoter" class="org.springframework.security.access.vote.RoleVoter"/>

Setting Security Properties on the Security Provider

You can add any additional properties to the security provider in the securityProperties map. For example, this map can be used to change Spring Security’s default security strategy into one of the following:

  • MODE_THREADLOCAL: allows the authentication to be set on the current thread (this is the default strategy used by Spring Security)

  • MODE_INHERITABLETHREADLOCAL: allows authentication to be inherited from the parent thread

  • MODE_GLOBAL: allows the authentication to be set on all threads

Securing Components in Asynchronous Systems

The use of Spring Security strategies is particularly useful for asynchronous systems, since we have to add a property on the security provider for the authentication to be set on more than one thread. In this case, we would use MODE_GLOBAL as shown in the following example:

    <mule-ss:delegate-security-provider name="memory-dao" delegate-ref="authenticationManager">
        <mule-ss::security-property name="securityMode" value="MODE_GLOBAL"/>

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub
Submit your feedback!
Share your thoughts to help us build the best documentation experience for you!
Take our latest survey!