Apigee Support for external Identity Provider (IDP)

[venkataraghavan]

How to enable an external IDP like ADFS with the edge ? How to go about enabling custom coding to facilitate this ?

[mschreuder]

There might be multiple parts to this answer. You need to be a Private Cloud customer to do these.

For DevPortal refer to the answer to Is there a way to use LDAP authentication instead of Apigee's authentication so that all internal us...

For Edge Management API / UI, in 4.15.04.00 an External Authentication feature was introduced, where you can set up config and have your Edge Management users authenticated via an external directory service like Active Directory. The details on how to configure are available in a separate document available to Private Cloud customers called "ApigeeEdgePrivateCloud-ExtAuthConfig".

This is authentication only, i.e. the validation of the user's password is done externally, but does not replace the Apigee Role Based Access Control, so you still need to provision the same users to Apigee and define their Roles there.

[sarthak]

This is a big topic and the question needs to be more specific. Based on the current question the various possible scenarios as as follows :

1. You need it for Dev portal.

Ans: Follow the link which Marc provided for LDAP.

If you want to SSO with external SSO providers like siteminders etc. use corresponding Drupal module and install them in Apigee Dev Portal. You can also create your own module and install in Apigee Dev Portal.

2. You need external Authentication for logging into Apigee EDGE management UI and APIs as admins.

Applicable only for on-prem customers today. We do not support this in Apigee cloud.

3. You need external authentication for runtime APIs i.e. the APIs proxied via Apigee.

a. You need external authentication for end users

In this scenario Apigee is acting as an Oauth provider. But Apigee needs to communicate with an external Authentication server like LDAP,ADFS etc. for end user credentials.

If LDAP for on-prem customers there is an OOB policy.

For other protocols like JDBC,AD etc. you will need to leverage node.js, java etc, inside Apigee.

b. There is a different Oauth provider at the backend

In this scenario Apigee is not acting as the Oauth provider but rather as a passthrough. You have an already existing Oauth provider like Ping Idenlty, something built in house etc. (I believe the latest version of ADFS can act as Oauth provider as well) and you have Oauth implemented in that software and you expect Apigee to passthrough the Oauth token etc. to the backend. This is definitely not desirable as you will be losing a number of benefits of OOB Apigee features.

In the above scenario to not lose Apigee benefits you might choose to utilize the API key generation function from Apigee . And once the keys are generated Apigee makes a call to the other oauth provider and send Apigee API Keys.

You might design the system other way round too i.e. the backend generates the API key and sends it to be stored in Apigee.

c. External authentication for storing end user credentials is Apigee BaaS.

It will be similar to any other external system , but there is an OOB node proxy available in EDGE to talk to BaaS.

All the above points are just at a high level. For the actual design of such a system lots more need to be considered. Eg. How are the key expiration times in sync between Apigee and backend , If using Apigee Oauth and using refresh token flow can backend handle refresh token concept etc.

Hope this helps.

[#4]

HI

Can you please provide more details on this

"In the above scenario to not lose Apigee benefits you might choose to utilize the API key generation function from Apigee . And once the keys are generated Apigee makes a call to the other oauth provider and send Apigee API Keys."

In this case will APIGEE do the authentication for OAUTH or it can still pass throught auth to backend and we will be able to still get all the analytics

Thanks

Vijay

[daniel_biales]

I was wondering if I could also get more details on 3b and how I could use apigee keys to pass through auth to the internal authentication provider

[santosh_ghalsas]

Hi @daniel.biales

The scenario that I worked on is similar to 3b -

You have an existing IDP on which users have been registered. Those users use the app(that is connected to IDP) and get access token issued by IDP(by giving user name and password). Then that access token is later passed to Apigee along with the api key and api secret to access the APIs hosted on Apigee.

Here Apigee will first authenticate if the app is a trusted client for this API(by validating api key and secret and then will talk with IDP to get the provided token validated. By doing this API validates both app and user of the app and then only give access to hosted APIs.

[#7]

are there any examples of this flow on github?

[#8]

@santosh_ghalsasi In your scenario, it seems that the app is registered with your IDP in some way that the IDP knows the app's Client ID and Client Secret in order to pass those to Apigee, is that correct?

[santosh_ghalsas]

Hi,

The connection beween IDP and app are independent of Apigee. IDP has an API to validate the token issues by Apigee and that API is being used by Apigee once it receives token from app.

[#10]

b. There is a different Oauth provider at the backend

In this scenario Apigee is not acting as the Oauth provider but rather as a passthrough. You have an already existing Oauth provider like Ping Idenlty, something built in house etc. (I believe the latest version of ADFS can act as Oauth provider as well) and you have Oauth implemented in that software and you expect Apigee to passthrough the Oauth token etc. to the backend. This is definitely not desirable as you will be losing a number of benefits of OOB Apigee features.

In the above scenario to not lose Apigee benefits you might choose to utilize the API key generation function from Apigee . And once the keys are generated Apigee makes a call to the other oauth provider and send Apigee API Keys.

You might design the system other way round too i.e. the backend generates the API key and sends it to be stored in Apigee.

@sarthak - in your answer above, you allude to losing OOB Apigee functionality if you defer to an oath provider like Ping Identity - can you elaborate on what Apigee functions are lost?

[#11]

@sarthak Could you give me more details about the 3.a, please?

[sarthak]

Do you have a specific question in mind around 3a?

[#13]

I'm trying to do a feature that is a login with. I want to use my database (MySQL) to create login and password of users. With these data, create a token on OAuth and manage the access. Do you understand me? That is possible on Apigee Edge?

[#14]

Which approach is best - between 3a and 3b and why?

[sarthak]

@RejeevChaturvedi It depends on if you have an OAuth provider or not. Most of large enterprises have a centralized IDP or multiple IDPs like Okta, PingIdentity, Active Directory etc. But not a lot of customers have centralized OAuth providers. Even if they have they are relatively new and not widely adopted.

So many customers, end up using Apigee as oAuth provider. One advantage sometimes is if API team uses Apigee as OAuth provider they can make changes to their security layer in a lot more agile, faster way compared to the rest of the enterprise. Which can be critical since API programs can run at a different pace than rest of enterprise. For example API programs may have need to adopt JWT or OIDC or different OAuth flows whereas the centralized OAuth server may not support it yet.