Case Study: Access Management 2.0 for the Enterprise
Although UMA's primary use cases have centered on individual people, the "users" who managed access to their own online resources, the UMA notion of authorization as a service also has relevance to modern enterprises that must secure APIs in a developer-friendly way.
Where once web access management (WAM) and single sign-on (SSO) were sufficient for many purposes in the enterprise context, a new requirement has surfaced: managing access to an enterprise's web APIs, not just web apps. Today's systems for managing this type of access have a number of challenges.
Using current WAM solutions to provide API security can be unfriendly to developers, complex, expensive, and likely proprietary (outside of the use of XACML). Mobile client applications struggle to deal with XML-based and SOAP-based security mechanisms.
Since it's currently overly complex to centralize access authorization, we find too much authorization code in applications, which slows service delivery by forcing developers to redevelop authorization logic, as well as hindering effective auditing and policy administration.
WAM solutions are not fully agnostic as to authentication method. WAM solutions previously could make simplifying assumptions about how users authenticate (typically username and password into a web app). With mobile applications, game consoles, and other device types, and with strong authentication needs increasing, old assumptions are no longer viable.
UMA makes the following solutions possible.
As a profile of OAuth 2.0 (IETF RFCs 6749 and 6750) that is complementary to OpenID Connect, UMA defines RESTful, JSON-based, standardized flows and constructs for coordinating the protection of any API or web resource that will be familiar to any developer already acquainted with OAuth. UMA's notion of machine-readable resource set and scope descriptions creates an access control mechanism that enables control over specific resource endpoints, not just domains. With UMA, developers can handle authorization tasks by calling simple REST/JSON endpoints; administrators don't have to deploy a web server agent or reverse proxy to enable centralization.
UMA defines interfaces between authorization servers and resource servers that, by default, enable centralized policy decision-making for improved service delivery, auditing, policy administration, and accountability, even in a very loosely coupled "public API" environment. Custom profiles enable flexibility to move the decision-making line outward to distributed applications, to account for local preferences in API ecosystems. UMA does not standardize a policy expression language, enabling the flexibility in policy expression and evaluation through XACML, other declarative policy languages, or procedural code as warranted by conditions.
UMA inherits an authentication-agnostic outlook from its OAuth base. It concentrates on authorization, not on authentication. It has been profiled to work with OpenID Connect to gather identity claims from whoever is attempting access, and enables true claims-based authorization.
In UMA trust model terminology, this scenario is in the category non-person entity (NPE) to person sharing. An organization – say, BusinessCo -- is the resource owner (technical term) and the Authorization Party (contractual term), acting on its own behalf. A human "resource owner agent" acts as a policy administrator, overseeing the rules that govern resource access.
BusinessCo would run a service that does whatever elements of the job of authorization it has chosen to centralize; this is the UMA authorization server. Think of this as a policy decision point (PDP), though UMA's default profile gives less than 100% of the decision-making responsibility to it, and the authorization server may in turn outsource actual decision-making to an XACML PDP or some other service. This service would also give this agent access to policy information point (PIP) functions in some fashion.
BusinessCo's protected resources would sit behind the enterprise apps and APIs it has chosen to expose; these are the UMA resource servers. Think of these as policy enforcement points (PEPs), though UMA's default profile gives a bit of decision-making responsibility to them.
Client web or mobile applications, wielded by enterprise resource users such as employees and partners, are UMA clients. Aeb service clients that operate autonomously, without human intervention, may also be UMA clients.
This scenario uses ordinary UMA flows, noting that it is a human resource server agent, not BusinessCo, that sets policy and possibly performs any policy-dictated manual intervention to enable access requests to go through. The company Gluu has produced a swimlane diagram to illustrate.
Gluu gave a demo of an enterprise UMA scenario at an UMA WG meeting on Jan 10, 2013; see the meeting notes.