Use – Managed Access (UMA) – 101 Session
User-Managed Access (UMA) – 101 Session
Tuesday 3B
Convener: Eve Maler, Kantara Initiative UMA Workgroup Chair
Notes-taker(s): Thomas Berry & Eve Maler
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
1. Notes Received from Thomas Berry:
User-Managed Access (UMA) 101
- OAuth enables constrained delegation of access to apps
- Alice to Apps by way of authorization server and resource server (A-T-D) Authorization, Token, Directory
- Benefits:
- Flexible, clever API security framework
- Alice can agree to app connections and also revoke them
- OpenID Connect does modern-day federation
- Benefits
- Layers identity/authentication tech with delegation/authorization tech
- Translates federated identity for mobile and the API economy
- Federation user, relaying party, identity provider (standard UserInfo endpoint)
- Benefits
- With other problems exist
- To OAuth, UMA adds cross-party sharing
- Alice (resource owner) needs to share with Bob (requesting party) [by way of client]
- By way of Authorization server (A and T) and Resource server
- Benefits
- Secure delegation
- Alice can be absent when Bob attempts access
- Helpful error handling for client applications
- Alice controls trust between a service that hosts her resources and a service that authorizes access to them
Authorization server :A T D R P I C
- Aggregation is not a solution: resource server exists in many Ns
- A Authorization
- T Token
- D Discovery
- R Resource integration
- P Permission
- I Token Introspection
- C Claims Interaction
- Imagine what delegation means to an autonomous third-party
UMA Experience Opportunities
UX (consent):
Share Button (ahead of time)
Opt-In (At run time)
Approve (After the fact)
Monitor (Anytime)
Withdraw (Anytime) - revoke
Benefits for service providers: a summary
- True secure delegation; no password sharing
- Scale permission-ing through self-service
- API-first protection strategy
- Foster compliance through standards
Benefits for individuals
- Choice in sharing with other parties
- Convenient sharing/approval with no outside influence
- Centralized monitoring and management
- Control of who/what/how at a fine grain
Typical use cases
- Alice to Bob (person to person)
- Discovering/aggregating pension accounts and sharing access to financial advisors
- Connected car data and car sharing
- Enterprise to Alice (initial RO is an organization)
- Enterprise API access management
- Access delegation between employees
- Alice to Alice (person to self/app)
- Proactive policy-based control of app connections
Profiled or referenced by:
- OpenID Foundation HEART Working Group (HEalth Relationship TRust)
- UK Department of Work and Pensions
- OpenMedReady Alliance
Forge Rock
Glue
ShareMedData
HIE of One/Trustee
IDENTOS
Pauldron
RedHat SSO (Keycloak)
WSO2
UMA in a nutshell
- developed at Kantara Initiative
- V1 done in 2015
- Leverages existing open standards
- OAuth and OpenID Connect and SAML (optional but popular)
- Specs contributed to IETF OAuth WG in Feb
- Profiled by multiple industry sectors
- Financial, Healthcard
- UMA business model effort supports legal licensing for personal digital assets
- Mother (guardian) manages sharing for child (data subject); child “ages in” to consent and starts to manage sharing herself
- Some 1:1 interop testing done; more soon?
Demonstration
- Patient Alice creates a policy to share with Dr. Erica; Alice selects her sharing preference and presses SHARE.
- Patient sharing is easy!
ForgeRock Identity Platform
- profile and privacy management dashboard — also access management module
- Rock ‘N’ Roll Supermarket demonstration
- Sharing (shared resources)
- Activity (account actions/history)
The marvelous spiral of delegated sharing, squared
- UMA grant of OAuth enables Alice-to-Bob
- UMA standardized an API for federated authorization at the AS to make it centralized
- There are nicknames for enhanced and new tokens to keep them straight
RFC 6749
UMA extension grant adds
- party-to-party: resource owner authorizes protected-resource access to clients used by requesting parties
- asynchronous: resource owner interactions are async with respect to the authorization grant
- Policies: resource owner can configure an AS with rules (policy conditions) for the grant of access, vs. just authorize/deny
- Such configurations are outside UMA’s scope
Resource owner | Client + Requesting party
UX: SHARE MONITOR WITHDRAW OPT-IN APPROVE
UMA federated authorization adds
- 1-to-n: multiple RS’s in different domains can use an AS in another domain
- “Protection API” automates resource protection
- Enables resource owner to monitor and control grant rules from one place
- Scope-grained control: Grants can increase/decrease by resource and scope
- Resources and scopes: RS registers resource details at the AS to manage their protection
docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html
Promises BLT business-legal-technical
UMA grant details
swim-lanes slide
Client’s first resource request is tokenless: this exists in WAM
- response includes a permission ticket to continue (allows AS discovery)
- Claims-based access control in the form of claims collection options
- Assessment and token issuance as guardrails
- RPTs upgraded, revocation, ...
The permission ticket: how you start building a bridge of trust
- Binds client, RS, and AS: Every entity may be loosely coupled; the whole flow needs to be bound
- Refreshed for security: The client can retry RPT requests after non-fatal...
Pushed claims scenario is the most common implementation; for wide-ish ecosystems
- AS is requesting party’s IdP and the client is the RP
- RS’s initial response to the client
- Client pushes its existing ID token to the token endpoint
- AS is in the primary audience for this token
- Somewhat resembles SSO or the OAuth assertion grant, where a token of expected type and contents is “turned on”
Really wide ecosystems
- (Details already seen)
- Claims interaction endpoint must have been declared in the discovery document to allow this flow
- The AS mediates gathering of claims from any source
- A key “metaclaim” to think about: consent to persist claims; kind of like a refresh token opportunity (persistent claims token [PCT])
- Resembles the authorization code grant, but can apply to non-unique identities and is repeatable and “buildable” (a model for cross party interaction)
Federated authorization
- RS registers resources: This is required for an AS to be “on the job”
- RS chooses permissions: the RS interprets the client’s tokenless resource request and requests permissions from the AS
- RS can introspect the RPT: UMA enhances the token introspection response object
- RO controls AS-RS trust: the protection API is OAuth-protected
UMA features
- Registering a resources puts it under protection
- Deregistering removes it from protection
- While registered, configuration changes can be made
Resource and scope registration
- The RS is authoritative for what its resource boundaries are
- It registers them as JSON-based descriptions
- There is a resource...
- Scopes can be simple strings or URIs that point to description documents
Permission endpoint
- RS interprets the clients tokenless (or insufficient-token)
- RS ...
Relevance for privacy beyond “empowered flows”
- features relevant to privacy regulations
- Work on well along on an ...
(Most) legal relationships in the business model
******************** ********************* ******************** ********************
2. Notes Received from Eve Maler:
Here is the bullet list of topics:
• Overview
• UMA in action
• The technical big picture
• The UMA grant
• Federated authorization
• Authorization assessment
• Privacy and business-legal-technical implications
Direct link to slide deck:
