OnPremise to Cloud API authentication

Introduction: The goal of this document is to document a second interop scenario for using OAuth2 with assertions (instead of client-secrets), for web-services API authentication between environments.

Scenario: The opposite of scenario #1. Acme’s IT department has decided to use Google Apps to host their employee’s Email, Calendars, etc. They have an on-premise system which monitors for employee compliance with sharing of intellectual property. They want that system to make API calls to the Google Email API to monitor employee messages. While we use Google Apps as the example service provider, it could be any API service in the cloud such as an API exposed by Salesforce, or an API exposed by a custom app running on Azuere.

Challenge: When the compliance system makes API calls to the Google Email API, how will it prove that it is in fact the application that is allowed to access the mailboxes of all employees. In particular, if an IT administrator is fired who had previously had access to the sourcecode of the compliance application, could they impersonate it to Google?

Evolution of Solutions: There are many ways to enable WidgetCloud->WidgetCustomers, however most enterprise IT departments are looking for a standard way of doing it that reduces the risk of stolen credentials. The following is a list of approaches from weaker to stronger:

    • Employee passwords: The IT department manages passwords centrally and allows the compliance application access to that list. The system then impersonates each employee when talking to the Google Email API.

    • OAuth1 full access shared-secret: Google allows the IT admin to register an OAuth CK that is allowed to access all employee data. The compliance application stores the CKS and makes OAuth1 calls to the Google Email API with a URL param for the target employee mailbox.

    • OAuth2 assertion using SAML token: Same as #2 but instead of using a shared-secret a SAML assertion is sent that is signed using the public key that the company already configured with Google for use by SAML. They plan to manually rotate the key, but hardly ever do.

    • OAuth1 scoped access: Same as #2 but the IT admin configures the OAuth CK to only have access to employee mailboxes and not other information like calendars.

    • OAuth1 scoped access public key: Same as #4 but instead of a shared-secret the IT admin generates a public/private key pair. They plan to manually rotate the key, but hardly ever do.

    • OAuth2 via STS: Same as #5, but the IT department runs a central identity system which manages the public/private key. The compliance system authenticates to that STS using Kerberos, and then asks the STS to get an OAuth2 access token from Google for a specific user’s mailbox. The central identity system enforces policy about which user’s, and which type of data, can be accessed by a particular on-premise app.

    • Standard Cloud Key: Same as #6, but the central identity system publishes an Internet accessible file with a public key that it rotates daily and the Google API system always uses the latest key to verify the identity of the Acme application

Vendor Status:

Google: In April Google will have support for an OAuth2 CK to give us the URL of a file with a rotating public key.

Azure: The Azure ACS team have been the leaders in this space since their includes of OAuth-WRAP support in the fall of 2009. They have added support for later drafts of OAuth2. I am trying to check on how ACS supports the scenario in this document.

Salesforce: Salesforce led the effort to define the first standard for an assertion token that can be used in OAuth2 instead of a client-secret. I am trying to check on how Salesforce supports the additional related scenarios in this document.

Ping: Ping Identity is one of the well-known STS products that already supports swapping a token of one format for another. I am trying to check on how Ping supports the scenario in this document.

Oracle: Oracle has also blogged about the market demand they see of this type of scenario. I am trying to check on how Oracle supports the scenario in this document.

VMWare: I am trying to check on how VMWare supports the scenario in this document.