(Michael Schwartz)
Book: “Securing the perimeter”
Chapter 9 - Identity management, Chapter 8 - UMA
Each chapter is half theory half examples.
The first part of the book presents the most important concepts and the second part is practical examples - how something works.
Chapters in the first half of the book are about: LDAPS, UMA, open ID, Proxy, etc.
The book contains a lot of other stuff like apache modules, libraries, and some other LDAP tools.
Maybe they will make another version of the book in a year.
UMA - everyone in the UMA group has a different take on UMA. My standpoint is an enterprise access management standpoint.
UMA starts when you call an API. To call an API you need a token.
Diagram has 3 parties: the client, resource server (RS) and the authorization server. The client is a piece of software that is connected to the person. It can be a website, mobile app, etc… A person is optional as you can have a machine to machine use case. There are important use cases for UMA which require a person. Whenever you think about the client, think connected to the person.
RS is the thing proxying the APIs or it is actual APIs. The authorization server is the software that issues the token.
The resource owner is the person or organization that controls the RS and potentially AS. Resource owner makes the policies of who can access what.
If you think about google calendar, another app on the phone will ask you whether you want to give them access to your data. File sharing requires giving access to other people’s data as the data owner is different than the requesting party.
Pension provider: if you’re using a piece of software to see your pension, the app needs to know that you’ve approved it. Complicated authorization scenario.
File sharing case: if you request access to a file, but your friend is not online at that time and then you have to wait for your friend to come online and approve the request. UMA doesn’t have that, it doesn’t require the other party to be online.
How does UMA start? The client is requesting an API, but he doesn’t have a token yet. Resource server checks if there is a token and whether the token has the right scopes. If YES, then allow, if NO there is a call the authorization server and return of a so-called permission ticket. Authorization server looks at the permission ticket, assesses the scopes required and decides whether to allow it or not.
In OpenID, you always call the authorization endpoint first and then the token endpoint. UMA is backward. You always call the token endpoint first, trying to get the token Because if you get a token first you don’t need to interact with the user.
Second slide from presentation: Including proxy between the client and the API Building of a plug-in. value token - GWT, reference token - some unguessable string The reference token checks whether the token has been processed already. If you don’t know what the reference token is, you can call the introspection endpoint and ask for a JSON equivalent of that reference token.
If the introspection call is properly authorized but the token is not active, does not exist on this server, or the protected resource is not allowed to introspect this particular token, then the authorization server MUST return an introspection response with the “active” field set to “false”. Note that to avoid disclosing too much of the authorization server’s state to a third party, the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive.
The critical pieces of information that we need from the token: which client was this token issued to and what scope was associated with this token.
Proxy part: We know what the request is, we know what the token means but should we actually proxy the request? It is up to the client developer to know what scopes are required in order to call the API we want to get to.
With UMA, the clients don’t need to know about the scopes, here is a ticket number which you can present to the AS and the AS will hopefully be able to give you the token you need to call the API you are asking for.
The good thing about UMA: scopes can be changed without the client.
Showing an example:
Scopes – they are just strings. We associate scopes with policies.
The idea: one scope in UMA could result in a number of policies, scopes are many to many keys because one scope or many scopes might reuse many policies.
Failure case: policy returns false. Key use case for UMA !!!
API to API - there is not much difference between UMA and OUA
In UMA a resource could be anything. It wouldn’t be scalable to have a policy for each record. You would have to trigger the policy of the URL.
OPA - open policy agent
If you have a lot of policies, then a PDP makes sense.
UMA policy case - we request a token and the authorization server denies it. UMA gives a response called “need_info”, you get a new reference ID (new code) - we can’t give you a token but we can redirect you to the AS The authorization server can now put you through a multi-step workflow.
Airline and car rental example: Car rental API requires to see that you have given consent - (failed to get a token) - we need to interact with the user - we are waiting for a specific person to approve it - authorization server presents the login pages.
UMA Grampt - about 10 pages
