Child pages
  • UMA Implementer's Guide
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

 UMA Implementer's Guide

Abstract 

This document is a non-normative set of auxiliary material produced by the User-Managed Access Work Group. It records advice to and discussions relevant to developers of UMA-conforming software systems, services, and applications.

Status

This document is currently under active development.

Editors
  • Eve Maler, Maciej Machulak
Intellectual Property Notice

The User-Managed Access Work Group operates under Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version) and the publication of this document is governed by the policies outlined in this option.


Table of Contents 


Introduction

The User-Managed Access Work Group operates under Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version) and the publication of this document is governed by the policies outlined in this option.


Organizations as Resource Owners and Requesting Parties

TBS - when two-legged pattern for PAT/AAT (client credentials) is appropriate; autonomous web service clients


Managing Resource Registration Revisions 

Regarding the resource set registration API, it is common practice when using NoSQL databases to replicate entity tag (ETag HTTP header) revision information in the body of the response message as well, in a _rev property. The API does not mandate this property, however.


Ensuring Resource Server Access to an Authorization Server When the Resource Owner Is Offline

A protection API token (PAT) is an OAuth access token that needs to work in a number of circumstances when the resource owner is offline. When a client attempts access to a protected resource, requiring the resource server to use runtime portions of the protection API, the resource owner is not assumed to be present. At this point, any interactions with the resource owner, for example, access approval workflows, are conducted out of band of the protocol.

Many use cases assume that the resource owner is explicitly "offline", for example, unconscious in a hospital emergency room. Some anticipate that the resource owner may end up "permanently offline" after having asked for the PAT to be issued (such as "digital death" scenarios, which perhaps raise other long-term issues).

The authorization server thus needs to manage the issuance and expiration of the PAT and and any corresponding refresh token appropriately to ensure that the resource server has access when it needs it.


Handling Optional and Extension Properties

The UMA specifications (Section 1.1 in both) say "Any entity receiving or retrieving a JSON data structure SHOULD ignore extension properties it is unable to understand. Extension names that are unprotected from collisions are outside the scope of this specification." And in some cases, properties defined in the specifications are optional to supply (but, of course, required to be handled by the receiving entity).

This section recommends how to deal with optional and extension properties. It is helpful for handling behavior to be consistent because UMA flows involve loosely coupled entities. Typically, an extension property would appear if one of the entities has implemented some agreed extension to the specification that might not apply to this particular transaction.

In the event that an unrecognized property is received, we recommend logging the property and its value, taking normal precautions regarding safe methods of logging potentially dangerous properties in order to avoid injection attacks or similar. This will help with any troubleshooting or auditing that may be required, while allowing normal processing to continue. Finally, we also recommend logging any property that is malformed (for example, where a Boolean value is expected, but a text value is received), taking the same precautions regarding safe methods of logging.

Following are specific comments on optional properties that appear in the UMA specifications.

PropertyRecommendations
Core 1.4: Authorization server configuration data
claim_token_profiles_supportedProvided as a hint; no significant impact if ignored by any party.  Should be logged if ignored to help with troubleshooting.
uma_profiles_supportedProvided as a hint; no significant impact if ignored by any party.  Should be logged if ignored to help with troubleshooting.
dynamic_client_endpointAuthorization Server: implementations should take care to provide this parameter if support for the dynamic client registration feature is provided.  Failing to provide it (or providing it erroneously) can induce incorrect handling by clients or resource servers.
Clients, Resource Servers: if the parameter is not provided, clients and resources servers must assume that dynamic client registration is not possible, and should therefore not attempt such registration.
requesting_party_claims_endpointAuthorization Server: to avoid confusion, should provide this parameter if end-user RP claims gathering capability exists.
Core 3.3.2: RPT "Bearer" profile
exp

Authorization Server: since not providing this property implicitly means that the permission does not expire, the AS should take care only to ignore the parameter if a non-expiring permission is desired.  It may be sensible to consider always providing a value, even if far in the future, to avoid inadvertently granting permanent permissions.
Resource Server: if the parameter is provided, it must be adhered to.  If it is not, it may be sensible to consider applying an expiry date anyway, to avoid inadvertently allowing permanent access to a given resources.  It may also be sensible to log if this parameter is not provided (and, hence, long or permanent permission is given) for audit purposes.

iatAuthorization Server: Not providing the issued-at time introduces the potential for confusion at the RS about whether the token is valid or not.
Resource Server: RS should consider whether the issued-at time is reasonable (allowing for potential clock skew).  Ignoring the parameter, if provided, could introduce a risk of incorrectly processing a 'bad' token.
nbfAuthorization Server: failure to provide this parameter might result in access to a resource being granted earlier than intended.  The AS should consider providing a value to avoid any potential confusion.
Resource Server: if the parameter is provided, it must be adhered to. If a value is not provided, the RS should assume 'now' as the nbf, and log accordingly for audit purposes.
Core 3.4.1.2: Claims-gathering flows
nameAuthorization Server: not providing a value might cause processing confusion later.  The AS should consider providing this.
Client: the client should consider using this value when returning any eventual results to the AS, in order to avoid confusion.
friendly_nameAuthorization Server: no significant impact; although not providing a value means that the client will have to make assumptions about how to present the claim requirement to the user.
Client: no significant impact; although the client should consider using this value to help provide improved communication to the user.
claim_typeAuthorization Server: no significant impact.
Client: no significant impact.
claim_token_formatAuthorization Server: failing to provide this parameter might result in a token format being return that the AS cannot then process.  AS should consider providing this parameter to avoid confusion at the Client.
Client: if provided, client should take account of the acceptable token formats when it returns a token to the AS. Ignoring this parameter might result in a token being returned in a format which the AS cannot process.
issuerAuthorization Server: no significant impact.
Client: ignoring this parameter, if provided, might result in a token being returned from an issuing authority which is not acceptable to the AS (and so lead to a poor user experience).
Core 3.4.1.2.2: Client redirects requesting party to authorization server
redirect_uriAuthorization Server: no significant impact; although not providing a value means that the client will have to make assumptions about how to present the claim requirement to the user.
Client: no significant impact; although the client should consider using this value to help provide improved communication to the user.
stateAs noted in the spec, it is highly recommended that this parameter be included in order to avoid cross-site request forgery.
ticket (response)There are no circumstances in which this parameter can reasonably be ignored.
state (response)There are no circumstances in which this parameter can reasonably be ignored.
Core 4.2: UMA error responses
error_descriptionNo significant impact.
error_uriNo significant impact.
RSR 2.1: Scope descriptions
icon_uriResource Server: no significant impact
Authorization Server: should log that it is ignoring for troubleshooting purposes.
RSR 2.2: Resource set descriptions
uriResource Server: in many deployments, the network location for the resource set being registered will be provided by (or inferable from) the 'scope' parameter (which is required).  If not, however, the resource server will most likely use the 'uri' parameter to provide the network location.
Authorization Server: if the parameter is ignored, this should be logged for troubleshooting.  It is unlikely to be ignored in most common scenarios.
typeResource Server: this can be a helpful hint to provide to the AS.
Authorization Server: should log that it is ignoring for troubleshooting purposes.
icon_uriResource Server: no significant impact.
Authorization Server: should log that it is ignoring for troubleshooting purposes.
RSR 3: Error messages
error_descriptionResource Server: no significant impact.
Authorization Server: should log that it is ignoring for troubleshooting purposes.
error_uriResource Server: no significant impact.
Authorization Server: should log that it is ignoring for troubleshooting purposes.

 


Giving Non-RPT-Bearing Clients Success Responses 

TBS - what do do when responding with other than a 403


Redirects 

If the client is concerned about HTTP parameter substitution of the ticket value after an end-user requesting party is redirected back after claims gathering, it can verify that the ticket initially sent to the authorization server is the same value that is subsequently returned by the authorization server. To verify that the ticket is the same in a stateless fashion, the client can send the ticket value in the state parameter, ideally in encrypted form, and then compare them on receiving the response from the authorization server.


RPT Refreshing 

TBS - Sec 3.4.1: discuss implications of this: "Once the authorization server adds the requested authorization data, it returns an HTTP 200 (OK) status code with a response body containing the RPT with which it associates the requested authorization data. If the client did not present an RPT in the request for authorization data, the authorization server creates and returns a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the requested authorization data, which MAY be either the RPT that was in the request or a new one. Note: It is entirely an implementation issue whether the returned RPT is the same one that appeared in the request or a new RPT, and it is also an implementation issue whether the AS chooses to invalidate or retain the validity of the original RPT or any authorization data that was previously added to that RPT; to assist in client interoperability and token caching expectations, it is RECOMMENDED that authorization servers document their practices."


Change History 

Version Date Comment
Current Version (v. 10) Jun 07, 2015 13:48 Eve Maler
v. 50 Jan 29, 2018 19:11 Eve Maler
v. 49 Jan 09, 2018 23:08 Eve Maler:
Added the Why The PAT? section
v. 48 Jan 09, 2018 20:56 Eve Maler:
Corrected PDF version of IPR doc link and rationalized IPR header content so it's the same as in Release Notes
v. 47 Jan 09, 2018 18:54 Eve Maler
v. 46 Sep 17, 2017 15:43 Eve Maler
v. 45 Sep 17, 2017 15:42 Eve Maler
v. 44 Aug 20, 2017 18:49 Eve Maler
v. 43 Jun 06, 2017 17:08 Eve Maler
v. 42 Jun 06, 2017 17:08 Eve Maler
v. 41 Mar 13, 2017 00:46 Eve Maler
v. 40 Mar 13, 2017 00:28 Eve Maler
v. 39 Mar 12, 2017 20:30 Eve Maler
v. 38 Mar 12, 2017 20:29 Eve Maler
v. 37 Mar 12, 2017 20:01 Eve Maler
v. 36 Mar 09, 2017 11:11 Eve Maler
v. 35 Mar 09, 2017 11:01 Eve Maler
v. 34 Mar 08, 2017 18:35 Eve Maler
v. 33 Mar 08, 2017 18:30 Eve Maler
v. 32 Mar 08, 2017 18:21 Eve Maler
v. 31 Mar 08, 2017 18:10 Eve Maler
v. 30 Mar 08, 2017 15:01 Eve Maler
v. 29 Mar 08, 2017 14:03 Eve Maler
v. 28 Mar 08, 2017 13:19 Eve Maler
v. 27 Mar 08, 2017 12:58 Eve Maler
v. 26 Mar 08, 2017 09:13 Eve Maler
v. 25 Mar 08, 2017 09:11 Eve Maler
v. 24 Mar 08, 2017 08:58 Eve Maler
v. 23 Mar 07, 2017 23:38 Eve Maler
v. 22 Mar 07, 2017 22:38 Eve Maler
v. 21 Mar 07, 2017 21:46 Eve Maler
v. 20 Mar 07, 2017 21:08 Eve Maler
v. 19 Feb 22, 2017 22:06 Eve Maler
v. 18 Aug 29, 2016 13:57 Eve Maler
v. 17 Oct 13, 2015 20:19 Eve Maler
v. 16 Oct 01, 2015 17:23 Eve Maler
v. 15 Sep 22, 2015 11:53 Eve Maler
v. 14 Sep 22, 2015 11:52 Eve Maler
v. 13 Sep 22, 2015 11:52 Eve Maler
v. 12 Sep 22, 2015 11:41 Eve Maler
v. 11 Sep 21, 2015 22:41 Eve Maler
v. 10 Jun 07, 2015 13:48 Eve Maler
v. 9 Jun 07, 2015 13:27 Eve Maler
v. 8 May 12, 2015 13:29 Eve Maler
v. 7 May 12, 2015 13:25 Eve Maler
v. 6 Jan 01, 2015 02:43 Eve Maler
v. 5 Dec 24, 2014 19:27 Eve Maler
v. 4 Dec 20, 2014 17:59 Eve Maler
v. 3 Dec 20, 2014 14:21 Eve Maler
v. 2 Dec 20, 2014 13:47 Eve Maler
v. 1 Dec 20, 2014 13:41 Eve Maler

 

  • No labels