Scope & user role mapping

[#1]

What is the best practice to map IdP user roles with apigee products, proxies, routes?

Situation:

We use Apigee as a central API gateway with thousands of proxies and hundreds of products grouping these proxies.

Currently Apigee issues and validates access-token (authorization service).

User authentication is done in our own solution, but we are considering moving to IdP service.

We don't support different user roles so 'access-token' has default scope option.

We want to utilize IdP roles functionality in which users can execute different actions in regards of their role.

Upon successful user authentication Idp will provide JWT "Id_token" with claims inside.

In order for Apigee to generate 'access-token' with correct scope value I see two options:

a) Apigee has to be aware of IdP supported roles and have a 'map' which associate roles to correct (products, proxies & route) scopes?

b) Idp has to be aware of all proxy routes, products and provide scopes already defined with JWT "id_token"?

What is the best practice here?

[madhans]

Your IdP is the source of truth for User <-> Role mapping. Apigee is the source of truth for API resource <-> Scope mapping.

An user grants scopes to an app and hence scopes are closer to the operations of an app.

A role gives an user permission to perform certain operations in the system and hence is closer to the user.

Translating a role to a set of scopes may not be the best way. Apigee inherently manages the app and scope relationship. A backend tier could process role information (in a JWT) and enforce authorization.

[DChiesa]

I think a best practice is something similar to the (A) option you described, but with an extra element.

1. Configure Apigee (OAuthV2/GenerateAccessToken) to attach roles or groups to the tokenvia custom attributes, as asserted by the backend IdP
2. Configure the mapping of roles -> permissions in an external authorization service. This could also be a static table that is stored in KVM if the data is small enough.

What is this 2nd thing?

When Apigee Edge receive a valid OAuth token, it will automatically retrieve the user scopes associated to the token. The Apigee Edge proxy can then call to the Authorization service with a request including {role, route, verb} . The Authz service simply response "true" or "false" indicating that the request ought to be allowed or not.

The Authz service is really just a data table using all possible combinations of the tuple of {role, route, verb} as the key, and true/false as the value.

This is very similar to a XACML service, if you've heard of that. But there's no need to buy a complicated commercial service. It's really just a database lookup. The table looks like this:

role	route	verb	allowed?
reader	/accounts/*	GET	True
reader	/accounts/*	POST	False
writer	/accounts/*	POST	True

...and so on.