Authorization can take place in multiple places (and possibly multiple times). The AuthZEN WG has already proposed API gateway-level authorization checks. Another natural place where authorization checks can occur is in the authentication/federation layer. Identity providers become a natural coarse-grained Policy Enforcement Point. The following describes possible integration patterns to be considered for an IdP Profile of AuthZEN.
As an IdP, I want to check whether I can issue an access/identity token to a client. I call a PDP and ask Can I issue Alice an access token for this application/purpose?
. The PDP replies with a true
/false
decision.
This can be extended to refresh (and other kinds of) tokens.
As an IdP, I know the list of claims I can add inside the token. I create a boxcarred request and send it to a PDP: Can I give Alice claims A, B, C in the token I am minting?
. The PDP replies with an array of decisions e.g. [true, false, true]
.
As an IdP, I know the user. I need to know the claims (expressed as resources) the user can get access to. The IdP asks a PDP tell me which resources of type claim user Alice can access
. The PDP Resource Search API replies with a list of claims: [claim1, claim2...]
.
As an IdP, I know the user. I need to know the claims (expressed as resources) the user can get access to. The IdP asks a PDP tell me what a given user, Alice, can do
. The PDP Partial Evaluation API replies with a list of constraints that then need to be converted into a set of claims by the IdP.