Open ID Connect with Apigee

Hi all,

i was following this nice tutorial on OpenId with Edge

https://community.apigee.com/articles/29258/using-apigee-edge-with-openid-connect.html

clearly explianed. But i have a conceptual question:

The fact that in Apigee we can verify the signature of a (more or less trusted) OpenID provider like Google is enough to trust the user as well? Who knows who the users are? Of course duplicating identities in our system would make the use case with OpenID useless. So anyone can help to clarify?

thanks lot.

Solved Solved
1 3 620
1 ACCEPTED SOLUTION

I think you are asking a question about Federated Identity, in general.

And from your question, I suspect you know the answer.

Employing federated identity means system1 trusts the identity asserted by system2.

What system1 does with the information, is up to the designers of that system.

Probably you would want to augment identity with additional information; roles, authorizations, groups, other metadata. an identity provider like Google or Okta or Azure AD can track that stuff, but it might not track that kind of information. So you may have to track it yourself, in an independent database.

Something like this:

  1. Redirect client app to OpenID Connect signin
  2. Client app obtains JWT, sends to Apigee Edge
  3. Apigee Edge validates the JWT and extracts claims
  4. using the asserted (authentic) identity, Apigee Edge can call into an independent user database, to retrieve additional user-relevant information, like roles, groups, authorizations
  5. Apigee edge can then use that information to enforce authorization decisions

In many cases this independent user db might be augmented with a security policy server like Axiomatics Policy Server or Jericho Systems EnterSpace. So... you'd lookup the user to get groups, and then use the group to lookup authorization rules in the Authz server.

Finally, let me point out that the tutorial you cited covers two different cases:

  • building logic in an API Proxy that relies in the identity asserted by a third-party OpenID Connect provider (like Google)
  • building your own OpenID Connect provider using Apigee Edge

So you have options there. Many customers have a user database and want to produce their own OpenID Connect provider.

View solution in original post

3 REPLIES 3

I think you are asking a question about Federated Identity, in general.

And from your question, I suspect you know the answer.

Employing federated identity means system1 trusts the identity asserted by system2.

What system1 does with the information, is up to the designers of that system.

Probably you would want to augment identity with additional information; roles, authorizations, groups, other metadata. an identity provider like Google or Okta or Azure AD can track that stuff, but it might not track that kind of information. So you may have to track it yourself, in an independent database.

Something like this:

  1. Redirect client app to OpenID Connect signin
  2. Client app obtains JWT, sends to Apigee Edge
  3. Apigee Edge validates the JWT and extracts claims
  4. using the asserted (authentic) identity, Apigee Edge can call into an independent user database, to retrieve additional user-relevant information, like roles, groups, authorizations
  5. Apigee edge can then use that information to enforce authorization decisions

In many cases this independent user db might be augmented with a security policy server like Axiomatics Policy Server or Jericho Systems EnterSpace. So... you'd lookup the user to get groups, and then use the group to lookup authorization rules in the Authz server.

Finally, let me point out that the tutorial you cited covers two different cases:

  • building logic in an API Proxy that relies in the identity asserted by a third-party OpenID Connect provider (like Google)
  • building your own OpenID Connect provider using Apigee Edge

So you have options there. Many customers have a user database and want to produce their own OpenID Connect provider.

Thanks Dino. So you confirm that the System1 should also have knowledge of the third-party authenticated users in its own DB/internally.

And, yes another option is to build an own OpenID provider if we do not want to trust external IdP 😉

Am i right?

Yes, you are right!