We are happy to announce the June ’15 release of the Salesforce Connector v6.2.1. With this release, we now support 56 different operations across multiple Salesforce APIs including the Apex REST API. This release also includes significant authentication capabilities such as OAuth v2.0 JWT bearer token and OAuth v2.0 SAML bearer assertion.
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.
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:
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.