Google App Engine Integration: Your Legacy Apps are OAuth Enabled, Right?

Google just announced some major new features to App Engine.

In addition to offering Java (with an Eclipse plugin to follow) and a cron facility for scheduled jobs, they now offer a way to integrate your existing enterprise applications into App Engine.

From the announcement of Google Secure Data Connector (SDC) :

SDC provides the following functionality:

1. Secure link.Encrypts connectivity between Google Apps and your network. Google Apps is the only external service that can make requests over this connection.
2. Filters.Limits the scope of the types of requests that can be routed over SDC. You can configure filters to limit which gadgets, spreadsheets, and App Engine applications may access which internal systems. Filters may also be used to control which users can access and share data from your internal systems within Google Apps. You can use the user level filter control to augment the security provided by your internal system for verifying users and originating applications. Filters should not be used as a standalone authentication system.
3. OAuth Signed Fetch.Protects requests that are made through SDC. You can use Signed Fetch to authenticate requests from Google if your applications are OAuth aware. Note that SDC provides connectivity between Google Apps and your internal systems. If you do not use OAuth Signed Fetch, then SDC does not provide authentication.

In case pictures help, this is how it looks:

And these are steps:

1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel to SDC, which runs within a company’s internal network.
3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
5. An optional intranet firewall can be used to provide extra network security.
6. SDC performs a network request to the specified resource or services.
7. The service verifies the signed requests and if the user is authorized, returns the data.

This will enable a whole host of data mashups using an enterprise friendly language (Java).

What I found most interesting (beyond the network security issues of Google having a large tentacle into your network), is the API trust model relies on OAuth.  All the cool kids do OAuth these days, even Twitter recently joined the OAuth party.

Google are offering OAuth as the only mechanism to authenticate Google to your enterprise applications.

Which begs the question: how many of your legacy apps are OAuth enabled?  You don’t know?  Let me help you out here: None.

This is a case of Web 2.0 meeting Enterprise -1989.

How many of your legacy apps could even be OAuth enabled?  OK, take away the word legacy (there is an implicit insult when vendors call all your apps legacy), how many of your newfangled apps could support OAuth?  This question is worth asking as without OAuth support, there is no way to authenticate Google to your applications.   Hmmm, IP level controls OK?

If Google can drive OAuth into the enterprise then frankly, they would have done us a favour.  But how many organisations are going to be willing to re-engineer apps?  Of those that are, how many are just going to say ‘its OK, its no different from our partners accessing our database (hello?)…open the firewall’.

It will be really interesting to observe how enterprise application architects react with CloudVision(tm) react to this.  It will be even more interesting to measure the enterprise uptake of OAuth (I’m not holding my breath).