I am excited to announce Anypoint Platform’s support for ForgeRock’s OpenAM! As with the PingFederate support that came natively with the release of the Anypoint Platform for APIs last year, our new out-of-the-box support with OpenAM is seamless and can be configured for any organization with the push of a button. Once configured with OpenAM as an external identity provider, Anypoint Platform supports two key capabilities:
Securing an API in Anypoint Platform is easy. In a previous post we showed how Anypoint Platform for APIs allows you to fully protect your API. We concluded then that the combination of HTTPS and OAuth 2.0 are a rule-of-thumb best practice for Web API security. In this post, we’ll take a deeper dive into the makeup of a security configuration in Anypoint Platform and explore in more detail the areas of Basic Authentication and OAuth2 Authorization in the context of Identity Management. We’ll also give you some pointers about when and how to use these two standards.
Central to authentication in Mule is the Security Manager. This is the bridge between standard mule configuration and Spring Security beans. In the example we build in this blog, we will use Spring Security to authenticate credentials against an LDAP server. We suggest you read the Spring Documentation on this topic if you want to delve further.
It sounds like the title for a fantasy movie, but Google, OAuth and the “confused deputy” is a very common issue. Wikipedia defines a confused deputy as “a computer program that is innocently fooled by some other party into misusing its authority. It is a specific type of privilege escalation” (complete article here).
The Wikipedia article shares an example of a compiler exposed as a paid service. This compiler receives an input source code file and the path where the compiled binary is to be stored. This compiler also keeps a file called BILLING where billing information is updated each time a compilation is requested. If a user were to request a compilation setting the output path to “BILLING”, then the file would be overwritten and the billing information lost. In this case, the compiler is a “confused deputy” because although the client doesn’t have access to the file, it’s tricked the compiler (who does have access) into altering the file.
This post is brought to you by… you! Yes, a couple of weeks back I was writing about how dealing with OAuth2 secured APIs got way easier since Mule’s August 2013 Release. We got such a great feedback that we decided to incorporate some of it in our latest October 2013 release.
Token Management vs. Token Nightmare
So let’s do a quick recap. In the last post we said that now Mule is way smarter at automatically handling your tokens. So, in a single tenant scenario you could just do this:
Ever since Devkit made its first entry into the Mule family, a big variety of OAuth enabled Cloud Connectors were made available. Salesforce, Facebook, Twitter, Dropbox, LinkedIn and Google Apps suite are just some examples of the APIs we’ve connected to using that support.
When we started thinking about the August 2013 release we decided to take it one step forward and make it easier than ever. And now that Mule 3.5-andes is available on CloudHub, you’ll be able to leverage all these improvements into your integrations. On Premise users will also be able to use when the final version of Mule 3.5.0 is released as GA.
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.
Google Apps offers a cloud alternative to many of the office products. If you have a Gmail account then you have Google Apps including Spreadsheets, Docs, Presentations, Contacts, Calendars and Tasks. Of course Google Apps have APIS and of course we have the connectors to make it easy to connect Google Apps and your applications together. Lets get the connectors and then take a look at what you can do.
It’s a pleasure for me to introduce the Mule Dropbox Connector. I’m sure you have heard of Dropbox and many of you have been delighted by its simple features, and now you can take advantage of them in your Mule applications.
Getting the Dropbox Connector
It’s really easy to start using this connector thanks to Mule Studio update site. To install it:
- Go to the menu Help -> Install new software
- Enter the connectors releases repository: http://repository.mulesoft.org/connectors/releases
- Select the Dropbox Cloud Connector available in the Community group
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: