Good question
Let's break it down. There are different actors that you'd need to authenticate when addressing this problem:
- consumer developers. These are people who visit the developer portal, peruse the API catalog, perhaps subscribe to one or more APIs (== request or obtain app credentials), and so on.
- API publishers. These are people who publish APIs to the developer portal, maintain the API catalog. These are the API "owners".
- the Apps themselves. Consumer developers build apps. In the general case, an app sends an API request to an endpoint. Sometimes that app is being used dureclty by a person. Sometimes not! In the former case, the endpoint (probably Apigee) will want to authenticate the USER as well as the APP. In the latter case, the endpoint (Apigee) will want to authenticate the APP. Both the (optional) user and the (always present) app have credentials with which systems can authenticate them.
So when you tackle IAM and IdP, you need to take care to understand that these are three different types of actors, and in the general case, there may be three different identity systems issuing credentials for them!
The custom developer portal might use some third-party IdP to authenticate users, aka "consumer developers". Maybe ForgeRock, or Okta, or Auth0, or whatever. The devportal might use a SAML federation or OpenID Connect to allow users to authenticate via that third-party IdP. At that point the developer portal will have access to claims (like name, email address) of the visiting consumer developers, and will be able to rely on those claims, based on the portal-to-IdP trust relationship. The devportal can then decide what to show to the consumer developer based on those claims.
Separately, the developer portal might use a distinct IdP to authenticate the API publishers or owners. This might be a corporate Identity provider, like Azure Active Directory as an example. Okta is also used here, and others are also obviously possible. Even if the identity provider is the same, it's probably a different tenant. Publishers and consumers are different sets of people.
In the simple case, the devportal has a well-known "admin" account with a single password, and anyone that publishes to the portal logs in not with SAML, but via the well-known admin username and its password. At that point the person is treated as "super user".
The same sorts of things apply here: regardless of how the publisher user authenticates, the devportal can allow different access, different powers, to different people based on the identity (claims) asserted by the Identity Provider.
How you codify and enforce this access is completely up to you, when you build a custom developer portal.
The last type of "actor" is the app itself. Typically Apigee issues app credentials, in the form of client id + client secret (you can have other forms, like public/private keypairs). But in some cases you don't want Apigee to be the system-of-record for app credentials; you might want to delegate that to some other external system. Let's say Ping Federate. In that case the devportal should connect to that external key provider, generate a keypair, then send the generated keypair to Apigee for the specific app. At runtime, when the app sends those credentials into an Apigee endpoint, Apigee can authenticate them just as if Apigee had generated them independently.
Is this helpful?
LinkedIn
Twitter
