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.
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:
- Mule Security Manager – Client authentication and fine-grained 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.
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 Security.
Secure Token Service – OAuth 2.0 Provider
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.
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.)
The second set of Mule Enterprise Security features enables you to encrypt and decrypt the content of a message within a Mule flow.
Message encryption 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 encryption specifications and your favorite encryption algorithms. This feature is as straightforward as it gets, and makes message encryption, a potentially complex operation, very simple.
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.
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.
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.