...
UMA has the following actors and basic architecture (NOTE: we have aligned our terminology more closely with OAuth's, so expect a revised diagram very soon):
A number of historical articles and other materials about UMA are available:
...
Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is what UMA calls an "authorizing user"a "resource owner" who manages her calendar resource online. She might want to share her online calendar hercalendar information with a number of different parties for a variety of purposes, while not making it fully public to the whole world.
The calendar is known as a "protected resource", and Alice manages it at a web application we call called a "hostresource server". She could have many hosts resource servers for many different kinds of content she creates, along with other data about herself. In some cases, such as with credit scores, she can't actually control the values of data about herself.
The parties Alice wants to share her calendar with are called "requesting parties". They use "requesterclient" applications to attempt access.
In some cases, Alice herself is a requesting party in addition to being the authorizing usera resource owner, such as when she wants to share calendar data out to different calendar applications that she likes to use. We call this "person-to-self" sharing.
...
With UMA, Alice can manage all these types of sharing in a unified way, from a single web-application point of control we call called an "authorization managerserver" or AM. She can set policies that guide the AM authorization server in allowing or disallowing access by requesters clients to protected resources at hostsresource servers.
Further reading:
- UMA webinar from December 2011 (slides, recording)
- UMA Scenarios and Use Cases
- UMA 1.0 Core Protocol
...
Phase 1 of the UMA core protocol involves the authorizing user resource owner introducing the host resource server and AM authorization server so they can work together. Phases 2 and 3 together involve the requesting party, using a requesterclient, making an access attempt, being tested for suitability by the AM authorization server to receive a permission, and ultimately succeeding or failing in the attempt by presenting a token with permissions associated with it.
...
In fact, UMA is built on top of OAuth. But OAuth solves a somewhat simpler problem. Here are some features UMA adds to the picture.
OAuth in its typical deployment models solves for person-to-self sharing. UMA, in addition, solves for secure person-to-person sharing and person-to-organization sharing.
...
OAuth leaves unstated how its "authorization server" and "resource server" components interact. UMA fully defines a standard interface between its enhanced versions of these two components, the authorization manager and host.
Further reading:
- Blog entry with Venn diagram comparing OAuth, OpenID Connect, and UMA
- UMA webinar from December 2011 (slides, recording)
- UMA 1.0 Core Protocol
- UMA-OAuth comparison slides from May 2010
- UMA scoped access slides from May 2011
...
Yes. The UMA protocol has been defined on top of OAuth 2.0, and we try to keep up with OAuth drafts.
Further reading:
...
It now also references the OAuth dynamic client registration specification and a proposed OAuth token introspection specification, and it has defined a modularized proposal for resource set registration that we believe is valuable for OAuth generally and for OpenID Connect usage, as well as UMA usage.
Further reading:
Why doesn't UMA use OAuth terminology?
At first, UMA did try to use OAuth 1.0 terminology, such as "service provider" for the server side and "consumer" for the client side. As many others had found previously, "consumer" was particularly confusing because we wanted to put an emphasis on the individual who is controlling sharing actions, so we developed alternate terminology ("authorizing user", "requester", "host") and also named the special component that UMA uniquely introduced ("authorization manager").
With WRAP and then OAuth 2.0, OAuth's own terminology and componentry evolved in what we felt was a helpful direction (for example, separating the "resource server" from the "authorization server"). We have considered several times the question of adopting the newest OAuth terminology, but always end up sticking with UMA-specific terms in formal settings because the UMA parties and entities are enhanced and specialized versions of their OAuth counterparts.
If UMA goals get adopted in the OAuth post-2.0 work, we hope there will be formal opportunities to synchronize wording. In the meantime, in our design work and liaison conversations, we find the UMA and OAuth analogues do substitute nicely for each otherAs of late 2012, it does! Some of the UMA collateral still uses UMA-specific terminology, but we're moving to a world of authorization servers, resource servers, and clients.
The previous terms in UMA were authorization manager (AM), host, and requester.
Prior to that, they were relationship manager, service provider (SP), and consumer.
Further reading:
- UMA 1.0 Core Protocol, particularly the terminology section
- Latest OAuth 2.0 draft
- UMA historical materials
...
For now, UMA assumes that AM-issued tokens are opaque (not internally structured) and that, therefore, the AM authorization server responsible for having issued the token will be responsible for dereferencing it as necessary. Therefore, for example, the UMA protocol includes a way for a host resource server to make API calls to the AM to check the status of a token presented to it by a requester. However, we anticipate building in optional support for AM-issued tokens that use the JSON Web Token format, which will enable "local" validation without requiring a round trip to the server at run time.
...
Central to UMA is the notion of an access management console – a "digital footprint dashboard", if you will. The user can set up sharing rights between parties from this console, which is the user interface of the "authorization manager" or AM centralized authorization server component of UMA.
Because individuals are often at a power disadvantage compared to big companies and big websites, truly empowering people to control sharing is a tall order. The UMA Work Group has considered the problems it can tackle, and the ways in which a number of complementary efforts – such as trust and privacy frameworks – can be used in combination with it.
...
For example, the core UMA spec leverages OAuth for the authorizing userresource owner's introduction of the host resource server to the AMauthorization server. The core spec allows for both explicit (e.g., authorization code) and implicit (e.g., SAML assertion) forms of user consent for this connection. Profiling may be warranted to require only explicit methods, and even to dictate user experiences for consent and authorization.
As well, wherever various outside-of-UMA terms of service or strong authentication needs might come into play, such as in the authorizing user's mutual agreements forged with AM authorization or host resource server sites, or the strength of "assurance" about a requesting party's claims, profiling may be warranted to require certain terms of service or authentication or verification strengths, or alternatively membership in various trust frameworks that will dictate such answers.
...
Trust and Security Implications
How can an UMA
...
resource server be made responsible for incorrect or malicious behavior on its part? How does
...
resource/
...
authorization server trust work?
UMA requires a trust "dance" among several parties, who are aligned in some of their interests but who have divergent incentives in many other cases. The UMA Binding Obligations framework explains to what extent trust can be built between pairs of parties at a contractual level.
...
- UMA webinar from December 2011 (slides, recording)
- FAQ: What is required to make an UMA deployment model "legal" from a privacy, consent, and agency standpoint?
- UMA Binding Obligations framework
- UMA Binding Obligations slide deck
- Blog post: UMA: Trust in a distributed authorization system
UMA Usage in the Real World
What implementations of UMA are there?
We are aware of three major implementations so far: the SMARTAM project, an UMA project at Fraunhofer AISEC, and an UMA connector with the TAS3 standard being built by Synergetics. We are planning interop activities for early in 2012.
The SMART implementation makes it easy to integrate your application as a host or requester into an UMA-compliant SMART ecosystem. Check out the SMARTAM implementation FAQ for details.
...
- from a privacy, consent, and agency standpoint?
- UMA Binding Obligations framework
- UMA Binding Obligations slide deck
- Blog post: UMA: Trust in a distributed authorization system
...
UMA Usage in the Real World
What implementations of UMA are there?
We are aware of four major implementations so far.
Further reading:
- Implementations page
- UMA webinar from December 2011 (slides, recording) – includes an extensive SMARTAM demo and information on other implementation projects
- SMARTAM implementation FAQ
- Fraunhofer AISEC implementation FAQ
...
For individual people interacting with the web, this model means that they can conveniently reuse any sharing circles (such as "friends and family" lists) they might have among all the Web applications and information they control. They can also set up criteria for access at a single place (the UMA AMauthorization manager) and then go about their lives, not necessarily having to be online and paying attention when someone wants access to their stuff.
...
What sort of entity might serve as an
...
UMA authorization server?
An UMA AM authorization server has a natural affinity with those who operate identity providers (IdPs). It's well known that any one IdP can't provide on-board storage of all information relevant to an individual, and this fact is now being recognized in the new OpenID Connect model of IdPs that mediate access to claims from other authorities. The Open Identity Exchange's Street Identity project shows the value of using an IdP as a "relationship manager" to gather user consent for sharing a claim (in this case, a verified street address) whose authoritative version resides elsewhere. UMA leverages OpenID Connect to enable IdPs to offer this kind of service to users, adding features unique to UMA along the way (such as sharing data with other people and organizations, not just "yourself" using a different app).
...