SlideShare a Scribd company logo

Mule SAML

•Download as PPT, PDF•
•
D.Rajesh Kumar
D.Rajesh Kumar

The document discusses Mule's support for SAML (Security Assertion Markup Language) for exchanging security information between federated systems. It notes that the current Mule implementation supports SAML 1.1 with CXF web services only. It provides instructions on adding the SAML module JAR, configuring the security manager and security realms, and configuring security filters on CXF endpoints. It also briefly describes the two SAML profiles: sender vouches and holder of key.

Related slideshows

Mulesoft ppt
Mulesoft pptMulesoft ppt
Mulesoft ppt
 
Mule fips
Mule fips Mule fips
Mule fips
 
Mule expression language - Part 1
Mule expression language - Part 1Mule expression language - Part 1
Mule expression language - Part 1
 
1 of 11
MULE –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"> </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.
Thank You

More Related Content

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