This session ended up being an introduction to the UMA 2 spec for a small group of people that hadn't heard of it, or hadn't dived very deep into it before.
Started off with the UMA flow, eventually drawn out:
- The RO (Alice) starts using the RS with the AS for controlling access to resources, so that RS acquires a PAT (protection API access token) at the AS for the RO.
- The RO creates a resource at the RS
- The RS registers that resource at the AS
- The AS returns an ID for the resource and (optionally, and in the case of AM) a URI at which the RO can set policy
Some time later...
- The RqP (Bob) uses the Client to attempt to access the resource at the RS
- The RS find the request to be insufficient to give access, so requests a ticket from the AS for the resource ID + some scope
- The AS returns the ticket
- The RS returns the ticket, along with details of where the AS can be found, to the Client
- The Client approaches the AS with the ticket using the UMA OAuth 2 grant type
- The AS evaluates policy on the resource
- The AS finds the request to be insufficient to grant a token, so the AS, Client and (optionally) the RqP interact with one another in order to agree sufficient claims for the RqP's identity
- The AS re-evaluates policy
- The AS grants a token
- The Client presents the token with the original request to the RS
- The RS passes the token to the AS to introspect the scope that has been granted for the resource
- The RS returns the resource to the client.
The session then continued to be a discussion of various use cases that UMA might be useful for. These use cases were generally similar to the ForgeRock demos, which can be found at the following links:
- https://vimeo.com/129739601 - Consent 2.0, from the Identity Summit 2015
- https://vimeo.com/153031657 - User Managed Access demo, from January 2016
- https://vimeo.com/179627762 - Using Authorization, Consent and Delegation right with UMA, from the Identity Summit 2016