Apigee Edge provides various ways to secure APIs leveraging your existing Identity provider for authentication and SSO. This article describes one such approach, where PingFederate is your Identity Provider, providing authentication and SSO capabilities for users accessing APIs published on Apigee Edge.
Use-case: Acme bank publishes various APIs on Apigee Edge and secures them with Apigee Edge provided OAuth services. Acme bank wants the customers to be authenticated against their Identity-Provider individually while requesting an access token from Apigee Edge. This way access tokens on Apigee Edge are tied to individual customers and are issued only after a successful authentication against the Identity Provider.
Key Requirements:
Apigee Edge to authenticate customers against PingFederate for issuing Access Tokens.
Apigee Edge to provides analytics based on Customer Ids associated to the Access Token.
Leverage Apigee Edge’s OAuth Services, API Products and Developer Portal while still retaining the user identity and authentication with existing Identity Provider(PingFederate).
Solution:
Apigee leverages standards based OpenID Connect flow to provide SSO based authentication of customers against Acme Banks Identity Provider (PingFederate).
Customers requests OAuth Access Tokens from Apigee Edge leveraging one of Client Id based OAuth Grant Types.
Apigee Edge is configured to authenticate the user against PingFederate leveraging OpenID Connect flow. Apigee Edge issues an OAuth Authorization Code Flow for OpenId based HTTP redirect request to PingFederate. PingFederate Authenticates the user, presents an optional consent screens and issues an Authorization Code to Apigee Edge.
Apigee Edge exchanges Access Token and ID Token with Authorization Code from PingFederate via a back channel call (Apigee Edge to PingFederate direct call). Apigee Edge verifies JWT based ID Token, and invoked /userinfo endpoint to retrieve additional attributes of the logged in customer.
Apigee Edge generates the access token based on the original client Id on behalf of the logged in customer and send the Access Token to customer.
Customer leverages this Access Token to access APIs published on Apigee Edge.
William, I have attached the the sample proxy that I have used for the demo, you will see two endpoint /token and /cb/external. User requests a access token using /token endpoint providing the oAuth client ID defined on Apigee and will be redirected to PingFederate which will after authentication in-turn redirect back on /cb/external endpoint.
The /cb/external will perform the OpenIdConnect handshake to get needed user info from PingFederate and returns the access_token back to the client.
I have added a readme file in the attached proxy package with pre requisites needed to use this policy.
If the user is not already authenticated, when Apigee send a redirect to PingFederate, PingFederate will not receive PF_Cookie: At this point PingFederate retains the referral_url and prompts the user with a Login Screen. Once the User Authenticates to PingFederate, it now shows the Consent Screen and issues an OpenId Connect Atz Code to Apigee.
I know it is a bit involved, like a HTTP Redirect ping pong. But it works.
Let me know if you have any questions or need more info.
The user identity is maintained by the browser in the cookie.
The lifetime of the access token and refresh token (if any) is stipulated by the designer of the Apigee API Proxy. You can choose the value you like. We recomment short lifetimes: perhaps 30 minutes and 24 hours.
Could you please explain about federate server configuration with apigee , i need to configure it in order to make above /token calls successful and get access token.
Is this flow hiding the OpenID Connect Flow from the Client? As I understand, the Client AuthN process (RFC7523) is being handled by the proxy rather than leaving that responsibility to the Client.
The one thing that makes me uncomfortable is the assembled redirect URI at the /token resource (proxy). It’s being defined with the scope as ‘scope=openid’, so the client should get a JWT rather than an opaque (oauth 2.0) string as the access_token.
The token is still JWT token, if you look at the flow PingFederate send a JWT ID Token back to Apigee. The OpenID contract is between PingFederate (IdP) and Apigee. Once Apigee authenticates the user using openId connect, Apigee can issue a opaque or JWT based on the original token request and its configuration from client.
