Interfacing Apigee with external Identity Provider

[#1]

We have some Spring webservices running on EC2 and an OpenAM instance that is authenticating users against a mainframe for security(authentication & authorization). We have customized our OpenAM installation and implemented our own IdRepo SPI to authenticate against mainframe users during API invocation. Now, we want to put an API GW in front of our EC2 instance (Spring Webservices as well as OpenAM) and expose (some of) the Spring webservices as REST APIs. To address security, we need to configure OpenAM as IdP and the API Gateway as the SP and configure SAML or OpenID Connect. The problem here is that our rest clients will be browserless, so we are wondering if Apigee supports this. We need a product that has support for SAML ECP or OpenID Connect. We have the constraint that our users and their (authentication & authorization) credentials live on the mainframe and have to be resolved during runtime using our OpenAM's customized IdRepo. We want to use these same user identities coming in from these browserless clients to the API Gateway. Is there a proven design pattern we could apply?

@Mukundha Madhavan & @sarthak, could you please give us tips?

[DChiesa]

I'm not able to understand exactly what you need. Details like "OpenAM" "IdRepo SPI" "mainframe" and "EC2" and "Spring" are not aiding my understanding.

I think you have some APIs.

I think you want to secure them.

I think there is a remotely-accessible identity provider (IdP) that authenticates users.

Do you wish to use opaque OAuth Bearer tokens? If yes,

In that case, you will need to use Password grant or authorization_code grant.

Authorization code requires a browser, or a trusted user agent. It is mostly intended for use with untrusted (third party) apps. Since you do not have a browser, and it sounds like the app is a trusted app, then... you can rule out authorization_code grant.

This leaves password grant.

The client passes something like this to the Apigee Edge:

POST /token
Content-type: application/x-www-form-urlencoded

grant_type=password&username=Chanchal&password=Secret123

This is just a OAuth v2.0 request-for-token via password grant. Configure Edge to pass the credentials to the remotely-accessible Identity Provider in a request for authentication. This format of this request will vary depending on the implementation of the IdP.

If the authentication request succeeds, then use GenerateAccessToken within Edge to generate a new oauth token. Attach the user name and other context returned from the IdP to the generated token with token attributes. Return the opaque token to the client.

That takes care of token issuance.

THEN, in the API proxies in Edge that protect the backend services, use VerifyAccessToken.

Does this cover what you need?

----

If you want to use OpenID Connect, I think it probably means JWT.

For that, token issuance can be done by any party, by any system that knows how to generate JWT. Apigee Edge could do that, or some other system ... I am not sure if OpenAM can do it. You may wish to build an external system to do that. BUT, OpenID Connect implies (AFAIK) a browser interaction, to support the 3-legged OAuth authorization_code flow.

And since your clients are browserless, I don't know how you'd implement that for the client (Requester) side. So I think you would need to rule out OpenID Connect.

[#3]

@Dino, thanks for refining my initial query, you hit the nail on its head indeed. Your explanation regarding usage of GenerateAccessToken & Verify AccessToken, pretty much, was the missing link I was looking for. Nevertheless, if we'd like to use delegated token generation (i.e. tokens generated by OpenAM) instead of Apigee token generation, how could that be achieved?

[AliceInAPILand]

Hi @Chanchal Kumar,

I believe you might be looking for delegated token management, where OAuth access tokens are generated my an external system other than Apigee, but can be verified by Apigee, on API call.

Here's the documentation on how this can be set up: http://docs.apigee.com/api-services/content/use-third-party-oauth-system.

Basically,

1) In the token generation flow of the API proxy, before the execution of the token generation step, you would have to make a callout to OpenAM with user credentials passed to the token generate call. If it's an authorized and authenticated user, have OpenAP return both access token as well as resource grants.

2) If authN & authR was successful, also set a runtime proxy context variable (using Assign Message policy): oauth_external_authorization_status to true

3) In Generate Access Token step in the OAuthv2 policy to use external access token configuration: use the <ExternalAccessToken> element to set the token value obtained from step 1, and use the <Attribute> element to set any resource grant indicators as custom attributes to the token.

The above steps ensure that when a token generation call is made by a client with the appropriate user/client creds, the API proxy handling that call on Edge (the one where the above config is done), will first reach out to OpenAM to authN & authR the client and user. It then generates an Access Token entry in the apigee OAuth store with the value set to the token returned by OpenAM, and the grants set in custom attributes. The token is then returned to client.

4) On token verification, using Verify Token operation config of the OAuthv2 policy, Apigee can then verify the token like any other token generated by Apigee.

There's an example to illustrate the use of external OAuth token management here: https://github.com/dzuluaga/apigee-tutorials/tree/master/apiproxies/musicapi-oauth-delegated-authent...

Do check it out, and let us know if this is the answer you were looking for.

Cheers,

Vidya