reza.shafii on Tuesday, November 6, 2012

Introducing Mule Enterprise Security

3

Service-Oriented Architectures (SOA) present unique security challenges due to loose service/application coupling and operations  running across trust boundaries.  To help our customers address these challenges, we have extended the Mule ESB platform security in several key areas and are making these extensions available through our Mule Enterprise Security package. This blog post will introduce the key components of that soon to be released package.

Product Overview

The first thing to know about Mule Enterprise Security is that it builds on top of Mule ESB Enterprise’s existing security capabilities. Mule ESB Enterprise already provides a solid set of security features, including:

The new capabilities included in Mule Enterprise Security extend these existing security features while leveraging the benefits associated with Mule flows such as support for streaming and the Mule Expression Language.

With that in mind, let’s take a tour of the new features that we are introducing with Mule Enterprise .

Secure Token Service – OAuth 2.0 Provider

We begin our tour of Mule Enterprise Security by introducing the first element of Mule Enterprise Identity – extended support for 2.0.

If you’re familiar with Mule’s Cloud Connector technology, you know that the Mule DevKit allows developers to easily create OAuth clients. Mule Enterprise Security enables you to use a Mule server to create a complete OAuth service. (If you are not familiar with OAuth and the terminology in this paragraph sounds a little confusing, you might want to dip into the world of OAuth with this excellent blog post.)

In a nutshell, these new capabilities allow you to easily create HTTP based APIs (REST- or SOAP-based), then protect them with OAuth 2.0. In other words, you can create a new API using a Mule flow and protect it by adding an OAuth Provider element. Your API will then demand a valid OAuth 2.0 token from a client before it allows access to the service.

Furthermore, you can let Mule take care of issuing and maintaining the OAuth tokens to any application – whether a mobile client, traditional web app, or Mule Cloud Connector app – that consumes the API exposed by your Mule flow. The diagram below illustrates this functionality.

One final note: Mule Enterprise Identity supports all OAuth 2.0 grant types. For a more detailed overview of the Mule Enterprise Identity OAuth features, you can have a look at our beta documentation.

Additional Mule Enterprise Identity capabilities are scheduled on our roadmap, but for now you can utilize the OAuth 2.0 support through the Mule Enterprise Security package.

Credentials

Mule applications often access other systems – databases and JMS brokers, for example – that are secured by credentials (usually in the form of a user ID and password). These credentials are typically stored within a property file packaged with the Mule deployment zip file; generally, Mule looks up these credentials at runtime.

However, storing the value of the credentials in plain text format can be a serious security threat since they are viewable to anybody with access to the Mule application (whether in the source control repository or within any of the application’s different runtime environments). This opens the door for unauthorized access and retrieval of information from any of the systems that are accessed by the application in question.

To address this issue, the Mule Enterprise Security Credentials Vault allows you to easily encrypt specific values of a Mule application’s property file to ensure that only the flows that need access to these property values can decrypt them. Mule Studio facilitates easy, GUI-based encryption of property file values (see figure below) thereby securing your users’ credentials into the vault. To access the vault, a sys admin must manually enter a key at runtime.  (Review the finer details in our documentation.)

Message Encryption

The second set of Mule Enterprise Security features enables you to encrypt and decrypt the content of a message within a Mule flow.

Message ensures that the content of the message cannot be understood if intercepted by a [potentially malicious] third party. To encrypt or decrypt a message (or in the case of XML, it can also be a specific XML element), Mule makes use of the Message Encryption element which supports XML-Enc, Java Cryptography Extension (JCE), and OpenPGP specifications and your favorite algorithms.  This feature is as straightforward as it gets, and makes message , a potentially complex operation, very simple.

Digital Signatures

Mule Enterprise Security introduces extensive support for digital signatures as well.

To protect against message interception and modification during transmission, digital signatures compute a secure hash value for the content of the message and include this hash within the message at the source. The hash can then be re-computed at the destination to verify that it has not been modified enroute, and that it was indeed sent by the entity claiming to be the source.

Once again, the support is based on the XML-DSig, JCE, and PGP specifications. Mule Enterprise Security introduces two new elements for making use of digital signatures within Mule flows:

  • you can apply an XML, JCE or PGP digital signature to the entire message payload, or just part of it
  • you can verify an XML, JCE or PGP signature associated with a message

These elements are extremely easy to configure and, as always with Mule, require only a couple of lines of XML (or one message processor in Studio) to get the job done.

 

Security Filters

Mule Enterprise Security also includes a set of message processors that perform security-related filtering of messages. These filters enable the following functionality:

  • IP Filter: Only processes messages originating from a specific set of IP addresses (or a range of IP addresses); all other messages are dropped.
  • Message Expiration Filter: Checks the timestamp of an incoming message to ensure that the same message has not already been processed. Coupled with the use of digital signatures, this filter can be used to protect against replay attacks where an intruder intercepts a message and sends it several times.
  • CRC 32 Filter: Verifies the content of a message against a CRC 32 “checksum” value embedded within the message by the message’s sender. This filter can be used to ensure that messages have not incurred any accidental errors during transmission.

These filters behave just like a standard Mule filter message processor, but their function happens to be security related.

Conclusion

This concludes our tour of the Mule Enterprise Security features. As you can see, the capabilities we’re introducing are quite extensive! You can find out more information about these features and even test drive them yourself by participating in our Beta program.  If you decide to take a sneak peek and have some feedback to offer on how to smooth out any of our rough Beta-edges, we’d love to hear from you.

Stay tuned for our GA release in December 2012.

No related posts.

Interested in 3 days of knowledge sharing, hands-on labs, industry focused sessions, and plenty of networking? Register for the premier integration event, CONNECT London »

3 Responses to “Introducing Mule Enterprise Security”

Distributed Weekly 180 — Scott Banwart's Blog November 9th, 2012, 1:17 am

[...] Introducing Mule Enterprise Security [...]

David April 9th, 2013, 12:34 am

I want to use Credentials Vault in my application. which version of mule studio it will be available. I am using mule studio 3.4 beta version.

Reza April 11th, 2013, 12:03 pm

Please have a look at the Mule Enterprise Documentation on mulesoft.org. It will have the details you need.

Leave a Comment