It is valuable to enable enterprises to centralize their policies and entltlements (scope generation) in an authorization server that they run, letting each SaaS vendor with which they contract run a resource server that respects those entitlements. The effect is to federate authorization, enabling the onboarding of SaaS partners as "authorization relying parties" (AzRPs) to an enterprise's "authorization provider" (AzP).
UMA enables business logic centralization, not just for an individual person's sharing preferences around access to their resources, but also for “classic” enterprise access management to SaaS-hosted resources. Employee single sign-on (SSO) into SaaS applications today typically works as follows:
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:
Thus, administrators for each company can maintain authorization policy in a single place.
Business SaaS applications typically offer a great deal of fine-grained access control, and this control is specific to each application. To the extent that OAuth-based scopes convey all of the grain necessary, scope-grained access options as registered through the resource set registration API and as associated with an UMA requesting party token (RPT) of the default type ("bearer") can suffice.
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.