Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

APIs by their nature are subdivisions of functionality exposed at a single domain, and would map well to arbitrarily fine-grained policy, for example, at the method or even parameter level. However, outside the use of XACML, authorization policy granularity is coarse in traditional solutions: group filtering or URL regular expression matching at most. Further, it is often impractical to act according to policies from multiple authoritative sources.

Proposed Improvements

UMA makes the following solutions possible.

...

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 flexibility in policy expression and evaluation through XACML, other declarative policy languages, or procedural code as warranted by conditions. It also has a fluid way to handle federated authorization policy.

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

...