Contact Free trial Login

Configuring the Spring Security Manager

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.

Use Spring Security 3.0 as a Security Manager inside of Mule. You can use any of the library’s security providers such as JAAS, LDAP, CAS (Yale Central Authentication service), and DAO. For more information on the elements you can configure for a Mule security manager, see Security Manager Configuration Reference.


The following example illustrates how to configure a single security provider on Mule, in this case an in-memory database of users. To configure the provider, we set up a <user-service> element and the <authentication-manager> to which Mule delegates.

<mule xmlns:tls="" xmlns:http="" xmlns:tracking="" xmlns="" xmlns:doc=""

    <ss:authentication-manager alias="authenticationManager">
        <ss:user-service id="userService">
          <ss:user name="user" password="password" authorities="ROLE_ADMIN" />
          <ss:user name="anon" password="anon" authorities="ROLE_ANON" />

      <mule-ss:delegate-security-provider name="memory-provider" delegate-ref="authenticationManager" />

  <http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration" />

  <flow name="SpringExample">
    <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
      <logger level="INFO" message="## received" doc:name="Logger"/>
      <http:basic-security-filter realm="mule-realm"/>
    <logger level="INFO" message="## passed security" doc:name="Logger"/>

Adding Spring Security References

To make Spring security work, you need to add XML schema declarations to your Mule App. Notice the above example includes the following references inside the root XML element:


Make sure you include these references, they are important and Studio does not add them automatically.

Security Filters

Security filters can be configured on an object to either authenticate inbound requests or attach credentials to outbound requests. For example, to configure an HTTP basic authorization filter on an HTTP connector, you would use the following connector security filter:

<http:basic-security-filter realm="mule-realm"/>

When a request is received, the authentication header is read from the request and authenticated against all security providers on the Security Manager. If you only want to validate on certain providers, you can supply a comma-separated list of security provider names.

<http:basic-security-filter realm="mule-realm" securityProviders="default,another"/>

The realm is an optional attribute required by some servers. You only need to set this attribute if required by the server on the other end.

Also you may have noticed that we specificed some roles for the users in the example but haven’t used it for filtering. If you want to filter requests based on the user’s role you should add an authorization filter after the security filter providing a comma separated list of the authorized roles with the special syntax shown below.

<http:basic-security-filter realm="mule-realm" />
<mule-ss:authorization-filter requiredAuthorities="#{ {'ROLE_ADMIN', 'ROLE_ANON'} }" />

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub