Case Study: Centralizing Business Logic for SaaS Services

Introduction

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).

Problem Scenario

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:

1. Company X contracts with SaaS1
2. Employees SSO in from web or native app, passing in role/group attributes
3. Company X’s policies at SaaS1 govern what features users can access
4. Company Y does the same at SaaS1, etc.
5. Company X does the same at SaaS2, etc.

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 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

Thus, administrators for each company can maintain authorization policy in a single place.

Solution Scenario and Discussion

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.