Apigee as OAuth Resource Server - PingFederate as OAuth Authorization Server with synchronized client IDs.

[naseerm]

This article describes slightly different approach from the approach described here: Where the client IDs are synchronized between Apigee Edge and PingFederate, instead of mapping an token metadata attribute to Apigee Client ID, this approach relies on pre synchronized client IDs between Apigee Edge and PingFederate.

Use-case: Acme bank publishes various API Products on Apigee Edge developer portal, for its various line of business developers and third party data aggregators. These various line of business developers and third party data aggregators are currently registered in PingFederate, and are already accessing existing legacy APIs using PingFederate issued access tokens. They are now interested in using developer portal and APIs published on Apigee Edge.

Key Requirements:

1. PingFederate remains as the OAuth Authorization Server.
2. Application maintains only one OAuth Access Token, in this case it will be the PingFederate issued token.
3. Application leverages Apigee features like: API-Products and Apps based access-controls, quotas, analytics etc.

Two part solution:

Part 1: Synchronizing Apigee Client IDs with PingFederate client IDs.

Part 2: Authenticating PingFederate issued Access Tokens on Apigee Edge.

Part 1: Client ID Sync:

One approach for synchronizing Client IDs between Apigee Edge and PingFederate is to enable approvals on API-Products, where by as and when a line of business developer or a third party data aggregator associates a API Product to an app a notification for approval is sent to the API owner. Apigee Edge API Owner can now approve and create a new client ID in Apigee Edge with a list of API Products selected by the developer. The new client ID will be same as the client ID in PingFederate.

Part 2: Authenticating PingFederate Access Tokens on Apigee Edge.

This part of the solution remains same as the parent use-case. The only difference will be: instead of using a custom token metadata attribute for client Id mapping, the same exact client ID is used that is sent by PingFederate as response to validate token API. Refer the screencast in the parent article.

Additional Considerations:

Along with all the additional considerations listed in the parent use-case, one thing that should be considered is in the approval process: when the API Owner is creating a new Client ID, he must delete auto generated client ID. Also too, he must know appropriate Client ID to create that matches the API-Products selected by the developer for this App.