MULE-ESB Beginner’s GuideDec5th 2015Author: D.RajeshKumar

TABLE OF CONTENTS

Introduction..................................................................................................................................5Mule Architecture...........................................................................................................................6Anypoint Studio Essentials...............................................................................................................10Mule Connectors.........................................................................................................................10

Endpoint-Based Connectors..................................................................................................10Operation-Based Connectors................................................................................................11Global Connector Configuration.............................................................................................11

Mule Components........................................................................................................................11Scripting Components..........................................................................................................11Web Service Components....................................................................................................12HTTP Component...............................................................................................................12

Mule Transformers.......................................................................................................................12Transformer Library.............................................................................................................12DataWeave Transformer......................................................................................................13

Mule Filters, Scopes, and Routers......................................................................................................13Mule Exception Strategies...............................................................................................................14

System Exceptions..............................................................................................................15Messaging Exceptions.........................................................................................................15

Securing................................................................................................................................... 15Anypoint Enterprise Security.............................................................................................................15

Why Do Applications Need Security?......................................................................................16Advantages of Anypoint Enterprise Security.............................................................................16

Configuring Security......................................................................................................................17PGP Security.............................................................................................................................17

Encrypting and Decrypting....................................................................................................17

Configuring the Security Manager................................................................................................19

Configuring the Key Manager........................................................................................................19

Configuring a Credential Accessor...............................................................................................20

Jaas Security..............................................................................................................................21Using the Jaas Configuration File...........................................................................................21Configuring the Provider in the Mule Configuration File............................................................22

Passing the Credentials Directly to the Provider........................................................................23Passing a Non-default Login Module.......................................................................................23Configuring the Security Filter on an Connector........................................................................23

SAML Module............................................................................................................................24Adding the SAML Module JAR......................................................................................................24

Configuring the Security Manager................................................................................................24

Configuring Security on an Connector.........................................................................................25

Choosing a SAML Profile......................................................................................................25Example............................................................................................................................26

Introduction

Mule is a lightweight integration platform that most widely used integration platform in the industry. Mule enables you to connect anything, anywhere. Rather than creating multiple point-to-point integrations between systems, services, APIs, and devices, you can use Mule to intelligently manage message routing, data mapping, orchestration, reliability, security, and scalability between nodes.

Mule Soft Gurus/Experts says Mule is so named because it “carries the heavy development load” of connecting systems.

MULE-ESB Integration advantages:

Helps to connect to any third party application easily using Mule

We can integrate the applications or systems on premise or in the cloud (Web/Standalone/ Enterprise applications).

Easily integrate anything from a “plain old Java object” (POJO) to a component from another framework.

Move your environment to cloud and communicate easily with cloud providers

Provides most of the standard/advanced security features for the applications

B2B e-commerce activities

Mule Architecture

Mule ESB is based on ideas from Enterprise Service Bus (ESB) architectures. The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your intranet or across the Internet. There are currently several commercial ESB implementations on the market. However, many of these provide limited functionality or are built on top of an existing application server or messaging server, locking you into that specific vendor. Mule ESB is vendor-neutral, so different vendor implementations can plug in to it. You are never locked in to a specific vendor when you use Mule ESB.

The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your intranet or across the Internet. There are currently several commercial ESB implementations on the market. However, many of these provide limited functionality or are built on top of an existing application server or messaging server, locking you into that specific vendor. Mule ESB is vendor-neutral, so different vendor implementations can plug in to it. You are never locked in to a specific vendor when you use Mule ESB.

Understanding Mule Concepts

Based on the concept of Event Driven Architecture (EDA), Mule works by responding to messages initiated by external resources (i.e. events). At the simplest level, Mule applications accept and process events as messages through several message processors plugged together in a flow. Alternatively, large or streaming messages can be processed as records in a batch job. Understanding the basic flow architecture and batch job structure is key to understanding Mule. Essentially every Mule flow contains a series of message processors that accept, then process messages. Mule applications

usually contain multiple linked flows and/or batch jobs, which, in combination, perform the integration required for your use case.

Elements in Mule

Flow is sequence of processing events

A Message enters a flow may pass a wide variety of processors.

Message Source is component consist of Request-Response Inbound End-point

Message Processors is processing your data using transformer or component

The advantage of networking your applications is that one application can send data to another application. However, many applications don't have the ability to read or process data coming from another application. Mule ESB solves this problem by providing a messaging framework that reads, transforms, and sends data as messages between applications. A message is simply a packet of data that can be handled and sent between applications on a specific channel (also called a queue).

Mule Message Structure:

Message Object consist Message

Message contains the mail message with header information and the header information is consist of inbound property and outbound property . Inbound property will be immutable. Below diagram illustrates the message structure.

Inbound properties are immutable, are automatically generated by the message source and cannot be set or manipulated by the user.  They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message’s lifecycle. A message retains its inbound properties only for the duration of the flow; when a message passes out of a flow.

Outbound properties are mutable; they are set during the course of a flow and can become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport. They contain metadata similar to that of an inbound property, but an outbound property is applied after the message enters the flow. Outbound properties can be set automatically by Mule or a user can set them by manually inserting one or more transformer elements in the flow. Note that if the message is passed to a new flow via a flow-ref rather than a connector, the outbound properties remain outbound properties rather than being converted to inbound properties 

Variables:

Variables are user-defined metadata about a message. Variables have three scopes: 

Flow variables apply only to the flow in which they exist.  Session variables apply across all flows within the same application.  Record variables apply to only to records processed as part of a batch.

Variables are temporary pieces of information about a message that are meant to be used by the application that is processing it, rather than passed along with the message to its destination. Thus, variables are more likely to be set by humans, whereas properties are more likely to be set and invoked by systems. However, there are no strict rules about how properties and variables should be used. 

Global Elements:

In Mule, a Global Element is one that you configure once, then reference many times from elements within multiple flows. Rather than repeatedly writing the same code to apply the same configuration to multiple elements in flows, you can create one global element that details your configurations or transport details. Then, you can instruct any number of elements across flows in your Mule application to reference the global element for specifics on how to behave. 

Global elements provide flexibility. An element can apply a global element’s configuration exactly as defined, or can enhance the global configuration with modifications.

Global elements are reusable. You can configure a global element just once, then share that configuration among building blocks of the same type. This is particularly useful when you have to define the connection details and login credentials for an external source, such as a SaaS application or database.

Global elements offer efficiency. Rather than changing the same configuration multiple times within many building blocks, you can change a configuration once, in the “master”, and Studio applies the changes to all that reference it. 

Anypoint Studio Essentials 

An Eclipse-based, integration development environment Anypoint Studio offers two development environments you can use to create applications:

A Visual Editor

An XML Editor

Whatever you place or code in one editor reflects in the other. This real-time reflection of changes is referred to as two-way editing

Mule Connectors

one or more external sources, such as files, databases, or Web services. Connectors can act as message sources by working as inbound endpoints, they can act as a message processor that performs an operation in middle of a flow, or they can fall at the end of a flow and act as the recipient of the final payload data. 

Connectors in Mule are either endpoint-based or operation-based. Endpoint-based connectors follow either a one-way or request-response exchange pattern and are often (but not always) named and based around a standard data communication protocol, such as FTP, JMS, and SMTP. Operation-based connectors follow an information exchange pattern based on the operation that you select and are often (but not always) named and based around one or more specific third-party APIs.

Endpoint-Based ConnectorsEndpoint based connectors are configured as either inbound or outbound endpoints in a flow. Inbound endpoints serve as a message source for a flow. Outbound endpoints can occur mid-flow or at the end of flows, and send information to external systems. 

Operation-Based ConnectorsWhen you add an operation-based connector to your flow, you immediately define a specific operation for that connector to perform.

Global Connector ConfigurationSome connectors require that connection information such as username, password, and security tokens be configured in a global element rather than at the level of the message processor within the flow. Many connectors of the same type in one application can reference the connector configuration at the global level. For operation-based connectors, the global connector configuration is mandatory, but for most endpoint-based connectors it is optional. 

Mule Components

Components are message processors which execute business logicon messages. They enable you to perform specific actions without writing any Mule-specific code. You can drop a component – a POJO, Spring bean, Java bean, or script – into a flow to perform almost any customized task within your Mule application. For example, you can use a component to verify that items on an invoice are in stock in a warehouse, or to update a database with a customer’s order history. 

Scripting ComponentsMule includes several scripting components that you can use in flows to execute custom business logic. These components enable you to drop a chunk of custom-written logic into your flow to act upon messages.

Web Service ComponentsAlso included are two components to facilitate exposing, consuming, and proxying Web services. The CXF component leverages the CXF framework Mule uses to support SOAP Web services; the REST component works with Jersey to support RESTful Web services; both are bound to HTTP.

HTTP ComponentFurther, Mule provides an HTTP component to facilitate working with calls over HTTP. Use the HTTP Static Resource Handler to easily serve up static content when called.

Mule Transformers

In a Mule flow, a Transformer prepares a message for further processing by enhancing or altering the contents of the message properties, variables, or payload. Data transformation is one of the most powerful functionalities of Mule: rather than spending a lot of time building a customized connection between resources or processors, you can just use a pre-built transformer to perform a standard data conversion. For example, if the message source in a flow receives data in XML format, but a downstream message processor expects a Java object, you can use an XML-to-Object transformer to convert the format of the message payload. 

Transformer LibraryOut of the box, Mule provides a set of standard transformers to handle the most common data transformation scenarios. Typically, these elements require minimal configuration so as to facilitate quick construction of applications that must juggle different data formats between resources and processors.  If Mule doesn’t have the particular transformer you need, you can arrange several transformers in a sequence to achieve the output you need. For example, if you need to implement an A-to-C transformation but no such transformer exists, you can arrange a sequence – A-to-B, B-to-C – which effectively simulates an A-to-C transformer. For example, to convert XML to JSON, use an XML-to-Object transformer followed by an Object-to-JSON transformer.

DataWeave TransformerBeyond transformation, there is one type of message processor in Mule that both converts and maps data: the DataWeave Transformer, labeled as Transform Messagein the palette. In addition to transforming data from one format to another, DataWeave can map an input field, such as last_name, to a different output field, such as family_name (see image below). Even better, it can map multiple fields, such as title, first_name, and last_name, to a composite output field such as full_name. It can retrieve session state information in a message to facilitate conditional message routing, it can use Mule expression evaluation to facilitate conditional value recalculation, it can even look up information in tables or other flows. 

Mule Filters, Scopes, and Routers

Mule filters evaluate a message to determine whether it can proceed through a flow. The simplest filters implement basic logic operators (such as and, or, and not), but these simple elements can be combined in various ways to specify complex logical conditions. For example, you can use a filter near the beginning of your flow to reject any requests from a particular range of IP addresses, or simply use a filter to reject any messages with a particular payload, or with a null payload.

Mule scopes work to encapsulate other message processors so that they function as a single unit. You might wrap several message processors together to form a transactional unit, so that they succeed or fail to process a message together, thus ensuring accurate updating of a database, for example. You might wrap several message processors together within a cache scope to store the result of their processing for reuse, or wrap a single message processor within a message enricher scope to add to a message payload without manipulating the original contents.

Mule routers – or flow controls, as they’re known in Anypoint Studio – function much as their name implies: to direct or otherwise control messages within a flow.

At times, flow controls act as splitters, resequencers, or aggregators, splitting messages into individual items for processing, resequencing message content, or aggregating split messages.

At times, they act as forks in the road, evaluating a message’s payload, properties, or variables, then routing to the message down a particular "pathway" according to those contents. Thus, flow controls facilitate content-based routing. For example, you can use a choice flow control to examine part of a message payload, then route the message to the first "pathway" for which the set condition evaluates to true, such as where an order exceeds $5,000.

Mule Exception Strategies

Mule provides numerous options for handling errors. Errors, or faults, that occur within Mule are referred to as exceptions; when an activity in your Mule instance fails, Mule throws an exception. To manage these exceptions, Mule allows you to configure exception strategies.

Mule’s default exception strategy — which implicitly applies to all Mule applications — manages errors (such as, thrown exceptions) in Mule flows. When your flows require more sophisticated error management, you can implement one or more exception strategies to construct precise, efficient protocols for handling errors.

From a high level perspective, errors that occur in Mule fall into one of two categories: System Exceptions, and Messaging Exceptions.

System ExceptionsMule invokes a System Exception Strategy when an exception is thrown at the system-level (i.e., when no message is involved, exceptions are handled by system exception strategies). For example, system exception strategies handle exceptions that occur:

During application start-up When a connection to an external system fails

Messaging Exceptions

Mule invokes a Messaging Exception Strategy whenever an exception is thrown within a flow. Whenever a message is involved, exceptions are handled by messaging exception strategies.

When a message being processed through a Mule flow throws an exception, normal flow execution stops. Mule transfers the message to the message processor sequence within the exception strategy. You can incorporate any number of message processors into an exception strategy to handle the exception precisely as you wish. The diagram below illustrates what happens when a message throws an exception.

Securing

Anypoint Enterprise Security

Anypoint Enterprise Security is a collection of security features that enforce secure access to information in Mule applications.

This suite of security features provides various methods for applying security to Mule Service-Oriented Architecture (SOA) implementations and Web services. The following security features bridge gaps between trust boundaries in applications:

Mule Secure Token Service (STS) OAuth 2.0a Provider Mule Credentials Vault Mule Message Encryption Processor Mule Digital Signature Processor Mule Filter Processor Mule CRC32 Processor

Install the Anypoint Enterprise Security update on your instance of Anypoint Studio Enterprise Edition 3.3.2 or later.

Why Do Applications Need Security?Businesses must ensure that the valuable information they store and make available through software applications and Web services is secure. Locked away and protected from unauthorized users and malicious attackers, protected resources — such as credit card information or Social Security numbers — must still be accessible to authorized legitimate users and systems in order to conduct business transactions. 

To provide secure access to information, applications and services can apply a variety of security measures. The suite of security features in Anypoint Enterprise Security enables developers to protect applications according to security requirements, prevent security breaches and facilitate authorized access to data. 

Advantages of Anypoint Enterprise Security

Anypoint Enterprise Security adds new features on top of of Mule ESB Enterprise’s existing security capabilities. Mule ESB already provides the following security features: 

Mule Security Manager , client authentication and authorization on inbound requests as well as credential mapping for outbound calls

LDAP  and third party identity management system integration Validation of inbound requests  through the SAML 2.0 federated identity standard Secure FTP (SFTP) Transport  that enables Mule flows to read and write to remote directories over

the SSH protocol.

In most cases the above features were accessible only to expert Mule developers who are very familiar with the Spring Security framework. Anypoint Enterprise Security expands the types of security available to apply to Mule applications and, through its accessibility in Studio, makes security features accessible to a broader range of skilled developers.

Compiled to form an easily-accessible, user-friendly collection, Anypoint Enterprise Security offers developers a clear, structured method for adding security to Mule ESB applications. Developers can easily drag-and-drop one or more security features into Mule flows in Studio, Mule ESB’s graphical user interface (GUI), and can find configuration support in Mule documentation. 

Configuring Security

Mule ESB allows you to authenticate requests via connectors using transport-specific or generic authentication methods. It also allows you to control method-level authorization on your components. The Security Manager is responsible for authenticating requests based on one or more security providers. 

PGP Security

This extension adds PGP security on connector communication. With PGP you can achieve end-to-end security communication with signed and encrypted messages between parties.

Encrypting and DecryptingTo encrypt and decrypt messages you need to configure the following elements:

A security manager: responsible of holding a security provider, which contains the key rings, and the encryption strategy to be used. This allows for the encryption of all messages using the same key or to facilitate the use of different key rings.

A key manager: which is responsible for reading the key rings. A credential accessor: which determines the key ring and key manager to be used to

encrypt/decrypt the message being processed.

A full example is shown below:

<spring:beans>    <spring:bean id="pgpKeyManager" class="org.mule.module.pgp.PGPKeyRingImpl" init-method="initialise">                           <spring:property name="publicKeyRingFileName" value="pubring.gpg"/>        <spring:property name="secretKeyRingFileName" value="secring.gpg"/>        <spring:property name="secretAliasId" value="${public.KeyId.LongValue}"/>            <spring:property name="secretPassphrase" value="${secret.Passphrase}"/>    </spring:bean>         <spring:bean id="credentialAccessor" class="com.somecompany.apps.AppCredentialAccessor">            <spring:property name="credentials" value="John Smith (TestingKey) <john.smith@somecompany.com>"/>        </spring:bean>   </spring:beans> <pgp:security-manager>    <pgp:security-provider name="pgpSecurityProvider" keyManager-ref="pgpKeyManager"/>        <pgp:keybased-encryption-strategy        name="keyBasedEncryptionStrategy"        keyManager-ref="pgpKeyManager"

        credentialsAccessor-ref="credentialAccessor"/></pgp:security-manager>

The pgpKeyManager (in the spring:beans tag) is the one responsible for reading the rings. You have to set all the parameters: public and secret rings, the alias id (the long value in the ring) and the secret passphrase. In the same section, you can see the credentials accessor which needs to implement the CredentialsAccessor interface basically returning the key id based on the message (MuleEvent). Finally thepgp:security-manager glues both beans.

You are ready to encrypt and decrypt messages in your flows. The following two flows show how to use the encrypt-transformer and decrypt-transformer to encrypt and decrypt files.

<flow name="processEncryptFiles">    <file:inbound-endpoint connector-ref="inputEncrypt"        path="file:///temp/fileInput" moveToDirectory="file:///temp/fileInputBackup"        moveToPattern="#[header:originalFilename].backup" transformer-refs="file2Bytes" />     <encrypt-transformer name="pgpEncrypt"        strategy-ref="keyBasedEncryptionStrategy" />     <file:outbound-endpoint connector-ref="output"        path="file:///temp/fileOutput" outputPattern="#[function:datestamp]-#[header:originalFilename]" /></flow> <flow name="processDecryptFiles">    <file:inbound-endpoint connector-ref="inputDecrypt"        path="file:///temp/fileOutput" moveToDirectory="file:///temp/fileOutputEncrypted"        moveToPattern="#[header:originalFilename].backup" transformer-refs="file2Bytes" />     <decrypt-transformer name="pgpDecrypt"        strategy-ref="keyBasedEncryptionStrategy" />     <file:outbound-endpoint connector-ref="output"        path="file:///temp/fileOutputDecrypted" outputPattern="#[function:datestamp]-#[header:originalFilename]" /></flow>

Configuring the Security ManagerTo configure the Security Manager you need to reference your key manager and your encryption strategy. The Key manager is simple a reference to your key manager ring.

Configuring the Key ManagerTo configure your key manager you have to create a spring bean as shown before. You will need to set the public and secret ring files, the alias id and the secret passphrase. As Mule uses the bouncy castle library to encrypt/decrypt messages we recommend to obtain the alias id (as a long value) using this library. If Mule does not find your id in the ring it will throw an exception and it will list all the available ids in your ring.

Configuring a Credential AccessorTo configure your credential accessor you need to define a class which determines your key id. For instance the following class (used in the example) returns always the same fixed string thus all the messages will be encrypted/decrypted using the same key id. If you need to use different key ids then return different strings according to the MuleEvent received as a parameter.

Java Class:

public class FakeCredentialAccessor implements CredentialsAccessor{    private String credentials = "John Smith (TestingKey) <john.smith@somecompany.com>";         public FakeCredentialAccessor()    {    }         public FakeCredentialAccessor(String string)    {        this.credentials = string;    }     public String getCredentials()    {        return credentials;    }     public void setCredentials(String credentials)    {        this.credentials = credentials;    }

     public Object getCredentials(MuleEvent event)    {        return this.credentials;    }     public void setCredentials(MuleEvent event, Object credentials)    {        // dummy    }}

Jaas Security

The JaasSimpleAuthenticationProvider is a security provider that provides a way to interact with the Jaas Authentication Service.

The security provider for Jaas can be configured in a couple of different ways. It allows you to configure Jaas either by passing to the provider a Jaas configuration file or by passing the required attributes directly to the JaasSimpleAuthenticationProvider. These two configuration methods are described below.

Using the Jaas Configuration FileUsually, JAAS authentication is performed in a pluggable fashion, so applications can remain independent from underlying authentication technologies.

jaasTest{   org.mule.module.jaas.loginmodule.DefaultLoginModule required   credentials="anon:anon;Marie.Rizzo:dragon;"};

The above example was saved in a file called jaas.conf. This file contains just one entry called com.ss.jaasTest, which is where the application we want to protect can be found. The entry specifies the login module that will be used to authenticate the user. As a login module, you can either use Mule’s DefaultLoginModule, one of the login modules that come with Sun, or else create your own. In this case, we have opted for Mule’s DefaultLoginModule.

The required flag that follows the login module specifies that the login module must succeed for the authentication to be considered successful. Additional flags are:

Required - The login module is required to succeed. If it succeeds or fails, authentication still continues to proceed down the login module list.

Requisite - The login module is required to succeed. If it succeeds, authentication continues down the login module list. If it fails, control immediately returns to the application.

Sufficient - The login module is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the login module list). If it fails, authentication continues down the login module list.

Optional - The login module is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the login module list.

The entry also specifies the credentials, in which we put a string of authorized users together with their passwords. The credentials are put here only when theDefaultLoginModule is going to be used, as the method in which the user names and passwords are obtained may vary from one login module to another.

The format of the credentials string must adhere to the following format if theDefaultLoginModule is going to be used:

<username>:<password>;

Configuring the Provider in the Mule Configuration File

12345678

<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xmlns:jaas="http://www.mulesource.org/schema/mule/jaas/2.2"       ...cut...

    <jaas:security-manager>        <jaas:security-provider name="jaasSecurityProvider" loginContextName="jaasTest" loginConfig="jaas.conf"/>    </jaas:security-manager>

Note that in the above, the loginContextName contains the same name of the entry as in the Jaas configuration file. This name will be used for creating the login context as well as to find the complete URL of the jaas.conf file.

Passing the Credentials Directly to the ProviderThe second option for the configuration of the JaasSimpleAuthenticationProvider is to pass the configuration details that would otherwise be found in the Jaas configuration file directly to the provider.

123

<jaas:security-manager>    <jaas:security-provider name="jaasSecurityProvider" loginContextName="jaasTest" credentials="anon:anon;Marie.Rizzo:dragon;"/></jaas:security-manager>

In the above configuration, note that we removed the property loginConfig and don’t need to pass any Jaas configuration file. Instead, we simply pass the credentials to the provider (using the same format as specified above). Since no login module is specified, the DefaultLoginModule is used.

Passing a Non-default Login ModuleThe third option is to enter your own login module.

123

<jaas:security-manager>    <jaas:security-provider name="jaasSecurityProvider" loginContextName="jaasTest" loginModule="com.sun.security.auth.module.NTLoginModule"/></jaas:security-manager>

In the above configuration, we have added the loginModule property, which allows you to specify the login module you want to use to authenticate the user. Since theNTLoginModule does not require you to input a list of accepted usernames and passwords, the property for the credentials was removed.

Configuring the Security Filter on an ConnectorYou can use JaasSecurityFilter as a security filter, as follows:

12

<inbound>    <inbound-endpoint address="vm://test">

345

        <jaas:jaas-security-filter/>    </inbound-endpoint></inbound>

SAML Module

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

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

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

12345

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

</mule>

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.

1234567891011

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

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

Configuring Security on an ConnectorOnce you’ve defined a security manager, you can configure security filters on CXF connectors 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.

123

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

<saml:cxf-security-filter certificate-alias="mulesaml" security-realm="no

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

ExampleSince 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 configure our flow to require a SAML subject of AllowGreetingServices. To our inbound connector we add a SAMLVerifyInterceptor with a callback, which checks for the correct SAML subject:

1234567

<spring:bean class="org.mule.module.saml.cxf.SAMLVerifyInterceptor">     <spring:property name="callback">          <spring:bean class="org.mule.example.security.VerifyAuthorization">               <spring:property name="subject" value="AllowGreetingServices" />          </spring:bean>     </spring:property></spring:bean>

public class VerifyAuthorization implements SAMLVerifyCallback{

    private String subject;         public SAMLAuthenticationAdapter verify(SAMLAuthenticationAdaptersamlAuthentication) throws SecurityException    {        SAMLSubject samlSubject = samlAuthentication.getSubject();        if (!samlSubject.getNameIdentifier().getName().equals(subject))        {            throw new UnauthorisedException(...cut...

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

12345678910111213141516171819

<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"AssertionID="_40082eadbf045476e26a107e4f37861d"IssueInstant="2015-11-17T02:26:06.569Z" Issuer="self"MajorVersion="1" MinorVersion="1">  <AuthenticationStatement AuthenticationInstant="2015-11-17T02:26:06.569Z"AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">    <Subject>      <NameIdentifier>AllowGreetingServices</NameIdentifier>      <SubjectConfirmation>        <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>      </SubjectConfirmation>    </Subject>  </AuthenticationStatement></Assertion>

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 (for example, an X.509 certificate from Verisign).

Reference:

Referred https://docs.mulesoft.com for the information on the mule topics