Try   HackMD

Introduction: Use Cases for AuthZEN Integration with Identity Providers

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.

Use Cases

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Control whether a token should be issued

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.

Determine what goes inside the token

As a boxcarred request

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 a search API call

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 a partial evaluation API call.

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.