Child pages
  • UMA Implementer's Guide

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

Anchor
ignored
ignored

...

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.

 

...

Anchor
non-403
non-403
Giving Non-RPT-Bearing Clients Success Responses 

...