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:
Mark Zuckenberg once said: “How can you connect the world if you leave out China”. Well, I now hereby say: “How can you connect the cloud if you leave out Google”. I know I don’t have his net worth, but I have a point nevertheless. Reality is that Google has done a great job building a Gazillion of different and very cool APIs and you’d be right to feel that it’s hard to keep their pace. To help you with that is that we proudly present to you the first release of the Google Cloud Connectors Suite.
Testing using an external API can be a PITA, especially if the API uses any HTTP Callbacks or redirects such as OAuth or WebHooks. If your using any callback functionality like this then the Service Provider needs a way to callback your application and therefore be accessible to the public Internet.
When you start integrating these APIs, it’s much easier to work on your local development machine, but these are usually behind firewalls, NAT, or are otherwise not able to provide a public URL and it’s not really feasible to push to a staging environment every time you want to test something.
So we need a way to make our local applications available to the Internet; there are a few good services and tools out there to help with this such as: Tunnlr, ProxyLocal, showoff.io or you can setup your own reverse SSH Tunnel if you already have a remote system to forward you requests.
In this post, I am going to use a service called LocalTunnel and show how we can share a local Mule application with the world and customize some Cloud Connectors to receive Callbacks locally.