Access Keys:
Skip to content (Access Key - 0)
Cancel    
Cancel   
 

SAML Module

Nov 19, 2009 17:18

Robin Pille

Jan 30, 2014 15:06

Mulesoft Current Mule Documentation

SAML Module

Mulesoft Documentation Page

Contents

SAML Module
Enterprise

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.

This module implements SAML 1.1.

Mule's CXF Module includes WS-Security with a SAML option that supports SAML 2.0. 

 

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.

Configuring the Security Manager

To use the features of the SAML module, add the SAML module namespace to your Mule configuration file as follows:

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.

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 Choosing a SAML Profile below.

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.

Additionally, you must create specific configurations for the various transports to instruct them to support SAML. For example, CXF has to be instructed to configure WSS4j for usage of SAML as WS-Security profile.

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.

For a more detailed description of these profiles and the use cases when they're appropriate, see the article in the SAP documentation here.

 

Example

Since SAML is used for single sign-on, authentication of the user is assumed to have already occurred, and the SAML token simply contains one or more subjects, which provide some information understood by other systems. In this case we will configure our flow to require a SAML subject of AllowGreetingServices. To our inbound endpoint we add a SAMLVerifyInterceptor with a callback, which will check for the correct SAML subject:

When the expected SAML token is added to the WS-Security header of the message, it looks like this:

To verify that the received SAML token is authentic, SAML offers two different modes of trust: Sender Vouches and Holder of Key. In this case, we are using Sender Vouches, which means that the sender of the message must be trusted (e.g., via a digital signature). In Holder of Key mode, the sender of the message does not matter, but the SAML token subject must contain a key from a trusted source (e.g., an X.509 certificate from Verisign).

 

Configuration Reference

SAML Module


Mule enterprise offers support for the Security Assertion Markup Language (SAML), a standard for exchange of security information between federated systems.

Security manager

Attributes of <security-manager...>

Name

Type

Required

Default

Description

Child Elements of <security-manager...>

Name

Cardinality

Description

saml-security-provider

0..1

A security provider that delegates authorization to some other provider.

Saml security provider A security provider that delegates authorization to some other provider.

Attributes of <saml-security-provider...>

Name

Type

Required

Default

Description

saml-version

samlVersion

no

1.1

default-realm

string

no

 

Child Elements of <saml-security-provider...>

Name

Cardinality

Description

abstract-key-provider

1..*

 

abstract-security-realm

1..*

 

Keystore provider

Attributes of <keystore-provider...>

Name

Type

Required

Default

Description

name

string

yes

 

key-store-file

string

yes

 

key-store-type

string

yes

 

key-store-password

string

yes

 

Child Elements of <keystore-provider...>

Name

Cardinality

Description

Sender vouches realm

Attributes of <sender-vouches-realm...>

Name

Type

Required

Default

Description

name

string

yes

 

key-provider-ref

name (no spaces)

yes

 

sign-key-alias

string

no

 

sign-key-password

string

no

 

resign-assertions

boolean

no

 

Child Elements of <sender-vouches-realm...>

Name

Cardinality

Description

Holder of key realm

Attributes of <holder-of-key-realm...>

Name

Type

Required

Default

Description

name

string

yes

 

key-provider-ref

name (no spaces)

yes

 

Child Elements of <holder-of-key-realm...>

Name

Cardinality

Description