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! Go to 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:
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:
So you have options there. Many customers have a user database and want to produce their own OpenID Connect provider.
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:
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:
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!
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |