101 Session / Introduction to UMA = User Managed Access
Introduction to User Managed Access (UMA)
Tuesday 3B
Convener: George Fletcher
Notes-taker(s): Eve Maler
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
UMA is based on OAuth. In OAuth, Alice shares access to resources “with herself” — to a service that she uses. George doesn’t share access to a photo with Eve, but to an app he uses. In UMA, George can share access to the photo with Eve. In OAuth, the user experience requires George to approve access at run time. In UMA, he can also arrange to share access ahead of time, or after Eve attempts photo access, and can monitor access over time, and can withdraw access over time as well.
So UMA gives resource owner-defined control, dealing with access requests from arbitrary clients.
Why is this important? Evolution beyond consent, consent at times other than run time, audit and transparency, mutual consent between parties, IoT identity combined with human identity and consent, etc.
UMA is now at V2.0, which is improved. UMA V1.0 had to invent a bunch of technologies, which ultimately matured elsewhere. The two specs are now broken up into an OAuth extension grant and a “federated authorization” interface between the resource server (say, a photo service) and the authorization server.
This interface lets the photo server inform the AS about just enough resource info to let Alice express her resource-sharing wishes. The AS-RS loose coupling enables the resource owner potentially to manage sharing in a central way and enables the RS to offload management of policy decision-making.
Q: What implementations are there? ForgeRock, Gluu, RedHat Keycloak (partial), MITREid Connect (open-source project), more; see the Implementations page on the Kantara UMA Work Group wiki, for which the short link is tinyurl.com/umawg.
The UMA grant flow starts with requesting party’s client making a request for the protected resource at the RS first, being told which AS to go to in an as_loc response, and being given a permission ticket. This structure is a means of saving state as the client moves to the AS and comes back to it possibly repeatedly.
Q: So I don’t have to have the same company doing the auth as hosting the data? Correct.
Resource registration is the process that allows outsourcing of authorization policy of RS endpoints to the AS.
Q: Does this satisfy GDPR? You can use it to help prove certain GDPR compliance aspects. The “BLT sandwich” session in the next hour has some implications for that too. The RS is going to want to be quite certain about honoring consent and its withdrawal.
The motivation for the “Legal” work of the UMA Work Group is: How to ensure enforcement given that the harm for policy violation is real? If George lets Eve download a photo where Eve agrees to adhere to some usage constraints, and Eve violates the agreements, what is George’s recourse?
Detailed use case using a calendar API: Alice first sets up a relationship between her “myCals” service (RS) to her “authZ4me” service (AS). This is achieved through a normal OAuth flow, and an access token (which UMA calls a protection API access token or PAT) is issued. The RS registers Alice’s calendar-related resources and scopes at the AS. Alice defines an authorization policy. Alice sends Bob an email with a URL in it — a plain URL in the clear, pointing to a resource that is protected. Bob uses a calendar client, called scheduleMe, to try and reach Alice’s calendar link. When it fails, Bob needs to prove who he is to satisfy Alice’s policy (and an UMA permission ticket begins to flow through these transactions). Ultimately, his client app gets an access token (which UMA calls a requesting party token or RPT) and he can access the resource.
For those who love detailed, almost-curl-command-level sequence diagrams, please see:
- tinyurl.com/uma2grantwsd (for the UMA 2.0 Grant spec)
- tinyurl.com/uma2fawsd (for the UMA 2.0 Federated Authorization spec)
The grant has the client-centric perspective and the federated authorization spec has the AS-RS perspective.
