This week I am at the European Identity Conference (EIC) in Munich mostly for the workshop on „User Managed Access“ (UMA) and for two panels I am on (Social Network Data Portability tomorrow at 2pm and one that has „Post Privacy“ as topic now which is at 3pm). Tuesday though was focused on UMA, first with a workshop and after that I coded a UMA prototype.
User Managed Access
So what is User Managed Access and what do you need it for?
First if all it’s a workgroup at the Kantara Initiative led by Eve Maler and will at some point eventually be fed into the IETF for making it a standard.
The main goal of the UMA group is to make distributed authorization as easy and flexible as possible. Imagine having some resource you have hosted on „Host“ and a „Requester“ wants to access it (think client/server or something like that). The Requester might itself not act on behalf of the user owning the resource but on some „requesting party“ (which also can be the same user).
Now the Host needs to make some decision if it grants access or not. In OAuth something like this is possible in that the user introduces the Requester to the Host first to transmit some access token. The limitation is though that the Requester needs to be known beforehand.
Moreover the answer to the access question should not be simply based on a yes/no answer given beforehand. Instead we might also want to base it on certain claims. E.g. the Requester might need to prove that the Requesting Party is >18 years or maybe that this party has a certain role in a company.
For this to work UMA (and now OAuth 2.0, too) introduces a Authorization Manager (AM) which does the permission handling.
Basically there are three steps:
- The user decides which AM he wants to use for a certain Host where he has some protected resource(s). The host is introduced to that AM, retrieves some metadata about the AM and then performs an OAuth request to obtain an AM access token which can be used later. This step is only done once in front.
- At some point a Requester wants access to that resource and tries to access it. It will receive a 401 Unauthorized and with it the location of the AM (a URL). The Requester will then contact that AM, receive a list of claims (or the user will be asked in-bound as in OAuth) and needs to fulfill them. Note that this can also take place asynchronously, e.g. the AM can send an email or SMS to the User to ask what to do. Then the Requester will eventually receive a normal OAuth access token. Lets call this the Host Access Token.
- The Requester now tries the request to the protected resource again, sending the Host Access Token with it. The Host then needs to verify this token with the Authorization Manager by using the AM Access Token. If everything is ok, access is granted.
(one remark: I am not sure how limited access is done with this, e.g. you might want to decide whether somebody can e.g. get your full calendar details or just free/busy)
You can read more about all this including a lot of use cases in my transcript of the UMA Workshop led by Eve Maler. The draft specification (which is work in progress) can be found here, the claims format here.
The prototype
Back in the day when UMA started, I was an active participant in the group but at some time had to drop because of time constraints and because the specification back then felt kinda complicated to implement. But luckily this has changed now. Thanks to the developments in OAuth and OAuth 2.0 the specification is now based on OAuth 2.0 which makes it much simpler than the original one.
But as a specification is only any good if you can implement it in a day I wanted to try it out right after the workshop on tuesday afternoon. The result can be found here and it’s a merged implementation of a UMA Host, Requester and Authorization Manager. I cheated a bit on step 1 and preintroduced them in code and I also did not implement the specification in all details (which makes it kinda insecure). The main process is in there though and for half a day work I am quite happy about the outcome.
The implementation hopefully also helps to identify misleading or missing parts in the specification which can then be fixed accordingly. I already made some comments via Diigo on the specification page.
So here is a screenshot of the Authorization Manager:
The code is open source and licensed under an MIT license.
The future goals for it are:
- Make it compliant to the specification while also working on the specification itself
- Split it into Host, Requester and Authorization Manager modules and try to make things into a library where possible
- Do a full fledged Authorization Manager implementation with audit, claims and so on.
All this depending on my spare time of course. There are also other implementations ongoing as you can see on the implementation page. This hopefully helps to also do proper interop testing.
All in all I am happy with the progress UMA did and here at the conference there also seems to be quite some interest in that work which also is motivating of course. So in case you are interested as well you might want to join the UMA workgroup at Kantara (which only involves agreeing to the IPR regulations).