On my previous 3-part blog, I showed how Mule ESB can be used to service-enable and orchestrate traditional on-premise technologies like an Oracle database and IBM Websphere MQ. Using Mule ESB, we created a service that accessed employee information from an Oracle database table and transmitted this to IBM WebSphere MQ. An observant customer I was showing this to noticed a security flaw with how sensitive employee information was being transmitted in plain text and also asked how the employee record can be sent to SalesForce.com. This blog will show how these can be easily addressed using MuleSoft’s AnyPoint Platform. We’ll make use of the PGP encryption features from AnyPoint Enterprise Security to encrypt the data before sending it to WebSphere MQ. Then, we’ll create another message flow to retrieve this message, decrypt it and send it to SalesForce.com using the AnyPoint Connector for SalesForce.com.
Security is an ever-present concern for IT. It can be a rather daunting area when one considers all of the different possible dangers and the large variety of solutions to address them. But, the aim of Enterprise Security really just boils down to establishing and maintaining various levels of access control. Mule itself has always facilitated secure message processing both at the level of the transport, the service layer and of the message . Mule configurations can include all that Spring Security has to offer giving, for example, easy access to an LDAP server for authentication and authorisation. On top of that Mule Applications can apply WS-Security thus facilitating, for example, the validation of incoming SAML messages. But in this post, rather than delve into all the details of the very extensive security feature set , I would rather approach the subject by considering the primary concerns that drive the need for security in a Service Oriented Architecture, how the industry as a whole has addressed those concerns, the consequent emergence of popular technologies based on this Industrial best practice and finally, the implementation of these technologies in Mule.
Enterprise integrations running across trust boundaries demand robust security solutions. Mule Enterprise Security enables end-to-end protection of your integration ecosystem. Join Reza Shafii, Director of Product Management at MuleSoft, to better understand how our enterprise-grade security solution can help you.
In this webinar, you will learn how to:
- Block unauthorized access to your systems
- Eliminate exposure of sensitive data and information
- Prevent attacks through proactive threat management
Presenter: Reza Shafii, Director of Product Management, MuleSoft, Inc.
Date: Thursday, January 10, 2013
Time: 8 AM PST / 11 PM EST
On this 10th ‘Day of Christmas’ Mule blog post, we tackle an increasingly important question in the world of APIs: Presume that you would like to create a remote API (which perhaps exposes some legacy business logic) for access by internal and/or external clients. How can you make sure that access to your API is protected in such a way that:
A) Only clients that you trust can access them;
B) Those clients can access your API through the explicit authorization of their end-users; and
C) The end-users can be authenticated with a central entity, *withouth* having to share their credentials with your API’s clients.
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:
As you probably know, Mule provides pretty good support for PGP encryption (check the related links for further info on Mule’s PGP support). What we’re going to do in this blog post is provide a step-by-step, real life use case for PGP encryption. We’ll take a ride all the way from key generation to Mule configuration.
Security around public cloud offerings has always been a major point of concern (and controversy) for users. How do cloud providers protect customer data? How is log data protected? How is the surrounding infrastructure secured? We previous talked about how iON stays up and running even through EC2 outages. Today, we will talk about iON security to show how we protect customer information and the infrastructure used in building iON.
Jasypt is an open source Java library which provides basic encryption capabilities using a high-level API. This library can be used with Mule to avoid clear text passwords for connectors and endpoints.First, download the latest Jasypt distribution, unpack it and copy icu4j and jasypt jars to MULE_HOME/lib/user directory.
If you reached this blog and you are not a Mule user (yet) keep reading, I will not cover anything Mule specific. If you are new to OAuth or want to get an introduction to its concepts this post is the right one!
Authentication is vital in any kind of system but it is even more relevant when it comes to the web. As the web grows, more and more sites rely on distributed services and cloud computing. As resources are spread all over the web, sharing them across multiple sites is not an unrealistic requirement considering the following scenarios: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services. In order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else it also provides these applications unlimited access to do as they wish.
Building a highly available and fault tolerant cloud platform comes with its share of challenges. What happens when components fail? What happens when the cloud itself experiences downtime? How is it possible to ensure customer apps are always available and their log data is never lost?
These are some of the very questions we ask ourselves when working through the iON architecture. With so many choices, both open-source and commercial, it can be difficult to know where to start, and is not unusual to experiment with several possible solutions before settling on the right technology stack.