| Network Working Group | D. Catalano, Ed. |
| Internet-Draft | Oracle |
| Intended status: Standards Track | M. Machulak |
| Expires: June 5, 2015 | Cloud Identity |
| December 2, 2014 |
User-Managed Access (UMA) Claim Profiles
draft-catalano-oauth-umaclaim-01
User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This specification defines UMA claim profiles that can be used by client applications with authorization servers to obtain the necessary authorization to access protected resources. This revision of the specification is part of the UMA "candidate V1.0" process.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
User-Managed Access [UMA] is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This specification defines UMA claim profiles that can be used by client applications with authorization servers to obtain the necessary authorization to access protected resources.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol properties and values are case sensitive. Configuration data structures and JSON data structures defined by this specification MAY contain extension properties that are not defined in this specification. Extension names that are unprotected from collisions are outside the scope of this specification.
This section defines the UMA claim profile for pushing SAML 2.0 assertions. Following is a summary:
Example:
POST /rpt_authorization HTTP/1.1
Host: www.nuveam.com
Authorization: Bearer jwfLG53^sad$#f
...
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de",
"claims": [
{
"claim_format": "https://docs.kantarainitiative.org/uma/profiles/claim-saml-1.0",
"claim_body": {
"saml_assertion": "PHNhbWxwOl...[omitted for brevity]...ZT"
}
}
]
}
This section defines the UMA claim profile for pushing OpenID Connct standard claims. Following is a summary:
Example:
POST /rpt_authorization HTTP/1.1
Host: www.nuveam.com
Authorization: Bearer jwfLG53^sad$#f
...
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de",
"claims": [
{
"claim_format": "https://docs.kantarainitiative.org/uma/profiles/claim-oidc-std-1.0",
"claim_body": {
"sub": "248289761001"
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "joedoe@example.com"
"email_verified": true
}
}
]
}
Where the authorization and client have a tightly established trust relationship, then the client can be preconfigured to provide the required claim information to the authorization server based on a custom schema. Following is a trivial example, where the client provides a user's identifier (in this case an email address) to the authorization server for policy evaluation.
Example:
POST /rpt_authorization HTTP/1.1
Host: www.nuveam.com
Authorization: Bearer jwfLG53^sad$#f
...
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de",
"claims": [
{
"type": "ci-nuveam-claims",
"value": { "email": "bob@company.example.com" }
}
]
}
Another example is where the client provides a richer set of attributes directly to the AS and these attributes are used for policy evaluation. Importantly, it is the AS that decides which attributes are used for policy evaluation and which are not.
Example:
POST /rpt_authorization HTTP/1.1
Host: www.nuveam.com
Authorization: Bearer jwfLG53^sad$#f
...
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de",
"claims": [
{
"type": "ci-nuveam-claims",
"value": { "email": "bob@gmail.com", "roles": [ "manager", "admin" ] }
}
]
}
We provide an example of a reply below (standard UMA reply):
Example:
HTTP/1.1 201 Created
Content-Type: application/json
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv2"
}
In case of custom attributes, the client does not necessarily use any specific protocol for obtaining user attributes. It can use a pre-established relationship with the AS to provide the required set of attributes.
TYPE = "custom"
VALUE = {custom defined}
TYPE = "claim-client-claims-oidc-1.0"
VALUE = {set of oidc reserved claims}
In this setting the AS and the Client have a pre-established trust relationship. The client may provide the AS with custom claims as well as with OpenID Connect user claims that can be used for policy evaluation. We provide an example of the request below.
Example:
POST /rpt_authorization HTTP/1.1
Host: www.nuveam.com
Authorization: Bearer jwfLG53^sad$#f
...
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de",
"claims": [
{
"type": "ci-nuveam-claims",
"value": { "roles": ["manager", "admin" }
},
{
"type": "claim-client-claims-oidc-1.0",
"value": { "email": "bob@gmail.com" }
}
]
}
In this section, we discuss three examples:
In this claim profile example, the Authorisation Server acts as an OIDC compliant RP. This flow is used in case the policies for a particular resource set use any of the existing reserved OIDC claims. Importantly, it is the AS that determines if OIDC claims should be used for policy evaluation. This information is not shared with the client application.
During this flow the AS acts according to the OpenID Connect protocol and this is outside of the UMA specification.
In this claim profile example, the Authorisation Server acts as an SAML compliant Service Provider. This flow is used in case the policies for a particular resource set require the use of the SAML protocol. Importantly, it is the AS that determines if the SAML protocol should be used for policy evaluation. This information is not shared with the client application.
During this flow the AS acts according to the SAML protocol and this is outside of the UMA specification.
In this claim profile example and after successful authentication of the RP, the AS can pull the required user attributes from a local user datastore (e.g. LDAP, Active Directory, and other SQL and NoSQL-datastores). This information can be used for policy evaluation.
Issues are captured at the project's GitHub site (https://github.com/xmlgrrl/UMA-Specifications/issues).
This document makes no request of IANA.
The current editor of this specification is Domenico Catalano of Oracle. The following people are co-authors:
Additional contributors to this specification include the Kantara UMA Work Group participants, a list of whom can be found at [UMAnitarians].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [UMA] | Hardjono, T., "User-Managed Access (UMA) Profile of OAuth 2.0", December 2013. |
| [UMAnitarians] | Maler, E., "UMA Participant Roster", July 2014. |
NOTE: To be removed by RFC editor before publication as an RFC.
See http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol for a list of code-breaking and other major changes made to this specification at various revision points.