LinkedIn
Twitter
Apigee Edge provides various ways to secure APIs leveraging your existing Identity provider for authentication and SSO. This article describes one such approach, where your Identity Provider and OAuth authorization server is PingFederate and Apigee Edge acts as OAuth resource server securing the APIs published on Edge. The use-case is based on below requirement.
Requirement: Ability for existing apps, using PingFederate OAuth tokens for authentication, to seamlessly consume APIs published on Apigee Edge while leveraging its API productization capabilities.
Additional key requirements:
- PingFederate remains as the OAuth Authorization Server.
- Application maintains only one OAuth Access Token, in this case it will be the PingFederate issued token.
- Application leverages Apigee features like: API-Products and Apps based access-controls, quotas, analytics etc.
To demonstrate the above scenario let us consider below use-case:
Use-case: Acme bank’s banking app currently leverages existing legacy APIs, secured by PingFederate for OAuth based authentication, for providing banking services. Acme bank now wants to publish two new services on Apigee Edge to provide enhanced financial services for its customers on its existing banking app. The two new services are “Financial Profile Analysis” and “Financial Profile Prediction” services, such that only customers who are subscribed to these services gets to access these features in the App.
Figure 1: High Level Overview
Solution: Apigee Edge acts as OAuth Resource Server, thereby enforcing the validity of the token, as well as validating access to corresponding API Products and Apps.
Solution Flow:
- Application requests an OAuth token from PingFederate.
- Application requests an API from Apigee Edge providing the OAuth token.
- Apigee Edge validates the token; upon successful validation services the request to the App; upon failing to validate the token at Apigee Edge, it requests PingFederate to validate the Token.
- PingFederate returns a validation success response along with Token Metadata.
- Apigee Edge leverages an agreed upon attribute in Token Metadata to map to a corresponding Apigee Edge OAuth client. There by dynamically associating Apigee OAuth client ID using agreed upon attribute. In this case it will be the user's subscription level attribute that will be used to map to a client ID on apigee.
- Upon successful mapping, an Apigee Edge OAuth token is generated that reuses the same PingFederate Token in the original request. This token uses same OAuth token that was part of the original request. The expiry time can be set to be same as the expiry time provided by PingFederate or any time that is less than the provided expiry based on the use-case.
- The only difference will be the client_id. The client_id in this case will be the Apigee Edge client_id mapping to corresponding App. (Note: the PingFederate client_id will be stored at Apigee for records and analytics).
- Upon issuing an Apigee Edge OAuth Token, the token is validated to ensure that the requested URI is allowed by this OAuth token.
- Backend service is invoked and response is served back to the App.
Below is the screencast of the above solution as a demo.
Additional Considerations:
OAuth Access Token revocation: As PingFederate receives any requests to revoke an Access Token, PingFederate can invoke a revoke API on Apigee Edge to revoke the corresponding saved access-token.
If you want to avoid PingFederate explicitly revoking saved token from Apigee whenever a token revocation is processed on PingFederate, one option is: you can save the token for a small time period that is considered safe for the token to be active after the Access Token is revoked. This way as soon as the time to live expires the token will no longer be in Apigee.
PingFederate OAuth Client ID revocation: As the PingFederate Client ID are self contained and are only scoped to PingFederate, there is no need to perform any operation on Apigee Edge.
Apigee OAuth Client ID revocation: As the client ID is revoked from Apigee: any access to API that corresponds to the API-Product that client ID is associated to, will be blocked. As Apigee client ID is scoped only to Apigee Edge, there is no need to perform any operation on PingFederate.
Token Metadata Mapping to Apigee Edge Client IDs: On Apigee Edge, client IDs can be created using management APIs of our choice; On PingFederate any user attribute or application attribute can be selected to be passed as additional token metadata attribute. This passed token metadata attribute can be used at apigee as one to one mapping to client ID OR a client ID can be looked up based on the attribute that is passed by PingFederate (The lookup mapping data can be stored in KVM or Apigee BaaS).
