The document discusses Mule's support for SAML (Security Assertion Markup Language) for exchanging security information between federated systems. Mule version 2.2.3 introduced support for SAML 1.1 when using CXF web services. Future versions will support additional transports. The SAML module is only available in the Mule Enterprise edition. The document provides instructions on configuring the SAML module, including adding the JAR, configuring the security manager with keystores and realms, and configuring security filters on CXF endpoints. It also describes the differences between the Sender Vouches and Holder-of-Key SAML profiles.

1. MULE –Security-SAMLMULE –Security-SAML

2. 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. 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. 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. 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. 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. 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. 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. 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. 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.