...
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.
...
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 Authorizing Party (contractual term), acting on its own behalf, protecting its own resources. A human "resource owner agent" acts as in a policy administrator, overseeing the rules that govern resource accessIT administrator role.
BusinessCo would run a service that does whatever elements of the authorization 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 web service). This service would also give this agent access to policy information expose policy administration point (PIPPAP) functions to the IT administrator 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; 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.
Solution Flow
...