Apigee as OAuth Provider - PingFederate as IdentityProvider : using OpenID Connect Flow

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:

  1. Apigee Edge to authenticate customers against PingFederate for issuing Access Tokens.
  2. Apigee Edge to provides analytics based on Customer Ids associated to the Access Token.
  3. 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).

4645-screen-shot-2017-04-10-at-93222-pm.png

Figure: High-level Overview of use-case

Solution Flow:

  1. Customers requests OAuth Access Tokens from Apigee Edge leveraging one of Client Id based OAuth Grant Types.
  2. 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.
  3. 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.
  4. 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.
  5. Customer leverages this Access Token to access APIs published on Apigee Edge.

Below screencast shows the end to end flow:

Comments
Not applicable

Can you provide an example of how this is accomplished in a proxy?

anilsr
Staff

@William Swayze , Welcome to Apigee Community !

Great Question, Feel free to post same as a new question for better visibility.

naseerm
Staff

openidconnectproxy.zip

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.

Not applicable

Hi Naseer, thank you very much for your example.

I'm testing it, but when it tries to connect

ipd.pingfederate.acmebank.com:9031

it is not reachable.

Is this just a mock URL, or you used it to test your proxy against pingfederate but now it is not reachable?

Best regards.

naseerm
Staff

Replace that with your PingFederate endpoint; I was using an test Ping Federate deployment.

-Naseer

latheefdudakula
Participant IV

@Naseer Mohammad

I have watched the example in your youtube channel , it had already acquired the access token and went on with consent form (recognizing the user).

If i am a new user (how could that flow start ) and how the long the access token is persisted ?

Thanks>

naseerm
Staff

Hi Latheef,

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.

Best

-Naseer

latheefdudakula
Participant IV

Thanks Naseer. If i understand correctly, user identity is maintained by PF_Cookie all the time .

How long the access tokens are valid and how we are achieving the refresh tokens?

Thanks,

Latheef D

dchiesa1
Staff

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.

But your scenario may be different.

Not applicable

Hi Naseer,Thanksalot forr above sample code.

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.

This would be great help 🙂

naseerm
Staff

Hi Mounika,

By federated Server configuration you mean federating among multiple IdPs or managing the configuration of a single IdP.

The current sample I have maintains the IdP configuration in Apigee KVM. Which in turn can be managed by Apigee management APIs.

Let me know if that is what you were looking for.

Best

-Naseer

Not applicable

Thanks for the reply Nazeer!!

Oauth Procy is normallu no target based... but why it is as per the above zipped code which is : openidconnectproxy.zip

rgonzalez-1
Participant I

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.

Am I missing something? Thanks!

naseerm
Staff

Ruben,

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.

Hope that clarifies your concern,

-Naseer

Version history
Last update:
‎04-10-2017 08:51 PM
Updated by: