Case Study: Centralizing Business Logic for SaaS Services

...

Thus, administrators for Company X, and Company Y, and each other company must maintain authorization policy in many places -- with each of the applications it contracts to use.

Proposed Improvements

UMA makes the following solution possible:

1. Company X runs an UMA authorization server
2. SaaS1’s published API functions as an UMA resource server thata onboards that onboards to that authorization server and respects UMA tokens issued by it, containing permissions based on Company X’s policies
3. Company X maintains central policies for SaaS1, SaaS2, etc., so that its authorization server functions as an authoritative “AzP” respected by each “AzRP” in the authorization ecosystem, akin to an "IdP" respected by each "RP" in an identity ecosystem
4. Company Y similarly maintains central policies for SaaS1, SaaS2, etc., so that its own authorization server functions as a different authoritative “AzP” respected by each “AzRP” in turn

...

Often, applications require truly fine-grained control, which may put pressure on a scope approach to authorization. As an example, Salesforce CRM lets customers define custom data fields, and control field-level access. In this case, a custom RPT profile, for example, one that conveys a combination of scopes (reflecting "AzP" decisions based on centralized business logic) and identity data such as identifiers, roles, and groups (reflecting "IdP" knowledge based on centralized identity management) can enable a practical mix of central and distributed policy management.

Solution Flow

This scenario uses ordinary UMA flows and proposes consideration of a custom RPT profile. 

...