MULE –Security-SAML

2

SAML Module

As of version 2.2.3, Mule enterprise offers support for the Security

Assertion Markup Language (SAML), which is a standard for exchange of

security information between federated systems. For more information on

SAML, see http://saml.xml.org/wiki/saml-wiki-knowledgebase.

3

SAML Module

Current support in Mule is limited to SAML 1.1 and CXF web services only. Future versions of Mule will support the use of SAML with other transports. The supported SAML module is only available in the enterprise edition of Mule, although an unsupported version is available on the MuleForge.

4

Using the SAML Module

This section describes how to configure the SAML module in your Mule configuration.

Adding the SAML Module JAR

The use the SAML module, the mule-module-saml JAR file must be in a location on the classpath of your application.

5

Configuring the Security Manager

<mule xmlns:saml="http://www.mulesource.org/schema/mule/saml" xsi:schemaLocation="http://www.mulesource.org/schema/mule/saml http://www.mulesource.org/schema/mule/saml/current/mule-saml.xsd"> <!-- Rest of your mule configuration -->

</mule>

6

Next, you configure the SAML security manager as shown below. The following example starts off with the definition of the SAML security manager and its accompanying security provider. The security provider specifies the default security realm to use by security filters if none is specified. This is especially useful in case you have only one security realm.

7

<saml:security-manager> <saml:saml-security-provider name="samlSecurityProvider" default-realm="senderVouches"> <saml:keystore-provider name="default-key-provider" key-store-file="classpath:saml.ks" key-store-type="JKS" key-store-password="changeit"/> <saml:sender-vouches-realm name="senderVouches" sign-key-alias="mulesaml" sign-key-password="changeit" key-provider-ref="default-key-provider" resign-assertions="true"/> <saml:holder-of-key-realm name="holderOfKey" key-provider-ref="default-key-provider" /> </saml:saml-security-provider></saml:security-manager>

8

Within the security provider, you define a key provider, which reads keys and certificates from a standard Java keystore file. You configure this file using the normal Spring options to define resources. In this case, the keystore is read from the classpath.

In this example, two security realms are defined. One uses the sender vouches SAML scheme and is also the default realm. The other is a holder of key realm. Both use the same key provider as defined above. For more information on these realms, see MULE3USER:Choosing a SAML Profile below.

9

Configuring Security on an Endpoint

Once you've defined a security manager, you can configure security filters on CXF endpoints as shown in the examples below. The first example does not specify a security realm, so the default realm is used. Both filters specify the same certificate that is used to verify the SAML assertions as issued by the assertion provider.

<saml:cxf-security-filter certificate-alias="mulesaml"/>

<saml:cxf-security-filter certificate-alias="mulesaml" security-realm="non-default"/>

10

Choosing a SAML Profile

SAML defines two different profiles: Sender-vouches (SV) and Holder-of-key (HOK).

The Sender Vouches profile means that the sender of a message is authorized to act for one of its users towards another system. In this case, the sender of the message vouches its correctness. If both systems trust each other, this profile is appropriate.Holder-of-key means that the user himself is authorized to perform the actions. In this case, the owner (holder) of the key is acting. If your target system trusts the token issuer (and therefore the user) you'll use Holder-of-key.