...
UMA inherits authentication agnosticism from OAuth. 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 (with simple group- or role-based policies a natural subset).
Solution Scenario
In An organization – say, BusinessCo -- publishes numerous APIs. BusinessCo authorizes which people, clients, and networks can access a subset of the APIs. BusinessCo, as a subsidiary of ParentCo, relies on ParentCo to provide some of the required authorization policies.
When BusinessCo publishes and UMA-protects an API, its resource server acts as a policy enforcement point (PEP). The RS relies on an UMA authorization server to as a policy decision point (PDP) for it. The PEP can query multiple authorization servers to ensure that all required authorizations have been granted, for example the policies of both BusinessCo and ParentCo. In UMA trust model terminology, this scenario is in the category category non-person entity (NPE) to person sharing. An organization – say, BusinessCo -- is both the resource owner (technical term) and the Authorizing Party (contractual term), acting on its own behalf, protecting its own resources. A human "resource owner agent" acts in a IT administrator role.BusinessCo runs a service that does whatever elements of the authorization job 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 (the authorization server may in turn outsource actual decision-making to an XACML PDP or some other web service). This service would also sharing because the resource owner is a corporate entity that also operates its own authorization server.
Enterprise resource users such as employees and partners operate client applications, such as web and mobile apps, in order to request access. How the respective PDPs make authorization decisions about these users and clients is up to the implementation. Each authorization server may itself be a policy information point (PIP) at which policies reside, or it may be a client of one or more PIP services. To understand the nature of the requesting party, a PDP might be sent SAML- or OpenID Connect-based tokens by the requesting party's client, or may itself need to call out to an identity provider.
The PDP service would expose policy administration point (PAP) functions to the IT administrator administrators in some fashion. The service may itself be a policy information point (PIP), or may call out to one or more PIPs. BusinessCo 's protected resources would sit behind the enterprise apps and APIs it has chosen to expose, some of which may be run and hosted by third-party SaaS vendors; these apps and APIs represent 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. Those users are variously Requesting Parties or Requesting Party Agentswould need the capability to express their access policies; for example, BusinessCo or ParentCo might interface a standard enterprise entitlements management system that expresses polices in XACML or some other standard language.
Third-party SaaS vendors used by BusinessCo could also use the UMA approach. The SaaS API is a resource server/PEP that allows access by BusinessCo employees only when such access aligns with BusinessCo's (and ParentCo’s) policies. In this case, the SaaS provider would register the relevant resource sets and scopes with BusinessCo's PDP, and BusinessCo (and ParentCo) would map which policies should be evaluated to grant those scopes.
Solution Flow
This scenario uses ordinary UMA flows, noting that it is a human "Authorizing Party 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.
...