Facilitator: James Phillpotts
- UMA as a specification
- OAuth 2.0 1 user access to access its own resources vs UMA access to a data that is owned by somebody else
- example google docs "share" button
- UMA1 specification used (fairly young spec from 2015)
- UMA is a specification that is not coupled together with any resource server type
- Resource set registration OAuth 2.0 standard UMA relies on
- Resource can be anything - a photo or an album or a list of filenames
- Policy is not part of the UMA spec
Resource owner uploads a resource, gets a URI from the authorisation server and through that URI the user can set who it shares the resource with. (Share button)
Client (does not know anything about having to be authorised first) who wants to access the resource goes to the resource server. The resource server - by the request type - sends the client to the authorisation server with an authorisation req token. The user then gets authorised for the given resource operation and can continue to the resource server.
example uses : hospital share your medical records with people (maybe all doctors but not nurses)
if resource server was sharepoint it wouldn't use sharepoints "roles" but it would have to understand the client requests that were authorised through the auth server
UMA criticism it can be very "chatty" can have X different requests, redirects before the client can get the resource. To get around this chattiness is to get access groups (tickets) for resources from the authorization server.
Use-cases are not known yet. We're searching for angles to develop UMA. Scalability? Complex use-cases? What users are want from UMA?
-- DEMO --
Instabook demo to show how UMA works (James Phillpotts's created demo)
Question to look up:
1 token / 1 resource or more?