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:
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:
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).
Attached is the SharedFlow Proxy used in this demo. one-time-external-oauth-as-token-validation-rev1-2.zip
I noticed you add the client_id as a form parameter which overrides the <ClienId/> in the store token. Do you know how to get this to work without setting the form param? Cause setting the form param wipes out the body if there is one.