Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7643

System for Cross-domain Identity Management: Core Schema

Pages: 104
Proposed Standard
Errata
Part 1 of 4 – Pages 1 to 13
None   None   Next

Top   ToC   RFC7643 - Page 1
Internet Engineering Task Force (IETF)                      P. Hunt, Ed.
Request for Comments: 7643                                        Oracle
Category: Standards Track                                     K. Grizzle
ISSN: 2070-1721                                                SailPoint
                                                           E. Wahlstroem
                                                        Nexus Technology
                                                            C. Mortimore
                                                              Salesforce
                                                          September 2015


        System for Cross-domain Identity Management: Core Schema

Abstract

The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7643.
Top   ToC   RFC7643 - Page 2
Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

1. Introduction and Overview .......................................3 1.1. Requirements Notation and Conventions ......................4 1.2. Definitions ................................................5 2. SCIM Schema .....................................................6 2.1. Attributes .................................................7 2.2. Attribute Characteristics ..................................8 2.3. Attribute Data Types .......................................8 2.3.1. String ..............................................9 2.3.2. Boolean .............................................9 2.3.3. Decimal ............................................10 2.3.4. Integer ............................................10 2.3.5. DateTime ...........................................10 2.3.6. Binary .............................................10 2.3.7. Reference ..........................................10 2.3.8. Complex ............................................11 2.4. Multi-Valued Attributes ...................................11 2.5. Unassigned and Null Values ................................13 3. SCIM Resources .................................................13 3.1. Common Attributes .........................................16 3.2. Defining New Resource Types ...............................18 3.3. Attribute Extensions to Resources .........................18 4. SCIM Core Resources and Extensions .............................19 4.1. "User" Resource Schema ....................................19 4.1.1. Singular Attributes ................................19 4.1.2. Multi-Valued Attributes ............................23 4.2. "Group" Resource Schema ...................................25 4.3. Enterprise User Schema Extension ..........................26 5. Service Provider Configuration Schema ..........................27 6. ResourceType Schema ............................................29 7. Schema Definition ..............................................30
Top   ToC   RFC7643 - Page 3
   8. JSON Representation ............................................34
      8.1. Minimal User Representation ...............................34
      8.2. Full User Representation ..................................35
      8.3. Enterprise User Extension Representation ..................39
      8.4. Group Representation ......................................43
      8.5. Service Provider Configuration Representation .............44
      8.6. Resource Type Representation ..............................46
      8.7. Schema Representation .....................................47
           8.7.1. Resource Schema Representation .....................47
           8.7.2. Service Provider Schema Representation .............74
   9. Security Considerations ........................................92
      9.1. Protocol ..................................................92
      9.2. Passwords and Other Sensitive Security Data ...............92
      9.3. Privacy ...................................................92
   10. IANA Considerations ...........................................94
      10.1. Registration of SCIM URN Sub-namespace and SCIM
            Registry .................................................94
      10.2. URN Sub-namespace for SCIM ...............................94
           10.2.1. Specification Template ............................95
      10.3. Registering SCIM Schemas .................................97
           10.3.1. Registration Procedure ............................97
           10.3.2. Schema Registration Template ......................98
      10.4. Initial SCIM Schema Registry .............................99
   11. References ...................................................100
      11.1. Normative References ....................................100
      11.2. Informative References ..................................101
   Acknowledgements .................................................103
   Authors' Addresses ...............................................104

1. Introduction and Overview

While there are existing standards for describing and exchanging user information, many of these standards can be difficult to implement and/or use; e.g., their wire protocols do not easily traverse firewalls and/or are not easily layered onto existing web protocols. As a result, many cloud providers implement non-standardized protocols for managing users within their services. This increases both the cost and complexity associated with organizations adopting products and services from multiple cloud providers, as they must perform redundant integration development. Similarly, cloud service providers seeking to interoperate with multiple application marketplaces or cloud identity providers would require pairwise integration. SCIM seeks to simplify this problem through an easily implemented specification suite that provides a common user schema and extension model, as well as a SCIM protocol document that defines exchanging this schema via an HTTP-based protocol [RFC7644]. The SCIM
Top   ToC   RFC7643 - Page 4
   specifications draw design input and feedback from existing
   identity-related protocols and schemas from a wide variety of sources
   including, but not limited to, existing services exposed by cloud
   providers, PortableContacts [PortableContacts], vCards [RFC6350], and
   Lightweight Directory Access Protocol (LDAP) directory services
   [RFC4512].

   The SCIM protocol is an application-level protocol for provisioning
   and managing identity data specified through SCIM schemas.  The
   protocol supports creation, modification, retrieval, and discovery of
   core identity resources such as Users and Groups, using a subset of
   the HTTP methods (GET for retrieval of resources; POST for creation,
   searching, and bulk modification; PUT for attribute replacement
   within resources; PATCH for partial update of attributes; and DELETE
   for removing resources).

   While the SCIM protocol and core schema specifications are intended
   to cover point-to-point scenarios, implementers and deployers should
   consider multi-hop and multi-party scenarios such as a service
   provider acting as a general profile service for in-domain
   applications (e.g., a directory), as well as scenarios where a
   service provider in turn passes information to a third-party service
   provider by acting as either a SCIM client or a SCIM service
   provider.  Implementers and deployers should carefully consider their
   service level agreements and privacy agreements when distributing or
   propagating personal information (see Section 9.3).

   This document provides a JSON-based schema and extension model for
   representing users and groups, as well as service provider
   configuration.  This schema is intended for exchange and use with
   cloud service providers and other cross-domain scenarios.

1.1. Requirements Notation and Conventions

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]. The key words "REQUIRED" and "OPTIONAL" are used throughout this document to indicate whether an attribute or schema element is required or optional. These key words may be used alone (e.g., "REQUIRED.") or in a sentence. If not specified, an attribute is considered to be optional. The word "DEFAULT" as used in Section 7 indicates that a "keyword" value for an attribute characteristic is the default behavior.
Top   ToC   RFC7643 - Page 5
   Throughout this document, values are quoted to indicate that they are
   to be taken literally.  When using these values in protocol messages,
   the quotes MUST NOT be used as part of the value.

   Throughout this document, figures may contain spaces and extra line
   wrapping to improve readability and accommodate space limitations.
   Similarly, some URIs contained within examples have been shortened
   for space and readability reasons.

1.2. Definitions

Service Provider An HTTP web application that provides identity information via the SCIM protocol. Client A website or application that uses the SCIM protocol to manage identity data maintained by the service provider. The client initiates SCIM HTTP requests to a target service provider. Provisioning Domain A provisioning domain is an administrative domain external to the domain of a service provider for legal or technical reasons. For example, a SCIM client in an enterprise (provisioning client) communicates with a SCIM service provider that is owned or controlled by a different legal entity. Resource Type A type of a resource that is managed by a service provider. The resource type defines the resource name, endpoint URL, schemas, and other metadata that indicate where a resource is managed and how it is composed, e.g., "User" or "Group". Resource An artifact that is managed by a service provider and that contains one or more attributes, e.g., "User" or "Group". Endpoint An endpoint for a service provider is a defined base path relative to the service provider's Base URI (see Section 1.3 of [RFC7644]), over which SCIM operations may be performed against SCIM resources. For example, assuming that the service provider's Base URI is "https://example.com/", "User" resources may be accessed at the "https://example.com/Users" or "https://example.com/v2/Users" endpoint (see Section 3.13 of [RFC7644] for details regarding protocol versioning, e.g., 'v2'). Service provider schemas MAY be returned from the "/Schemas" endpoint.
Top   ToC   RFC7643 - Page 6
   Schema
      A collection of attribute definitions that describe the contents
      of an entire or partial resource, e.g.,
      "urn:ietf:params:scim:schemas:core:2.0:User".  The attribute
      definitions specify the name of the attribute, and metadata such
      as type (e.g., string, binary), cardinality (singular, multi,
      complex), mutability, and returnability.

   Singular Attribute
      A resource attribute that contains 0..1 values, e.g.,
      "displayName".

   Multi-valued Attribute
      A resource attribute that contains 0..n values, e.g., "emails".

   Simple Attribute
      A singular or multi-valued attribute whose value is a primitive,
      e.g., "String".  A simple attribute MUST NOT contain
      sub-attributes.

   Complex Attribute
      A singular or multi-valued attribute whose value is a composition
      of one or more simple attributes; e.g., "addresses" has the
      sub-attributes "streetAddress", "locality", "postalCode", and
      "country".

   Sub-Attribute
      A simple attribute that is contained within a complex attribute.

2. SCIM Schema

A SCIM server provides a set of resources, the allowable contents of which are defined by a set of schema URIs and a resource type. SCIM's schema is not a document-centric one such as with [XML-Schema]. Instead, SCIM's support of schema is attribute based, where each attribute may have different type, mutability, cardinality, or returnability. Validation of documents and messages is always performed by an intended receiver, as specified by the SCIM specifications. Validation is performed by the receiver in the context of a SCIM protocol request (see [RFC7644]). For example, a SCIM service provider, upon receiving a request to replace an existing resource with a replacement JSON object, evaluates each asserted attribute based on its characteristics as defined in the relevant schema (e.g., mutability) and decides which attributes may be replaced or ignored.
Top   ToC   RFC7643 - Page 7
   This specification provides a minimal core schema for representing
   users and groups (resources), encompassing common attributes found in
   many existing deployments and schemas.  In addition to the minimal
   core schema, this document also specifies a standardized means by
   which service providers may extend schemas to define new resources
   and attributes in both standardized and service-provider-specific
   cases.

   Resources are categorized into common resource types such as "User"
   or "Group".  Collections of resources of the same type are usually
   contained within the same "container" ("folder") endpoint.

2.1. Attributes

A resource is a collection of attributes identified by one or more schemas. Minimally, an attribute consists of the attribute name and at least one simple or complex value, either of which may be multi-valued. For each attribute, a SCIM schema defines the data type, plurality, mutability, and other distinguishing features of an attribute. Attribute names are case insensitive and are often "camel-cased" (e.g., "camelCase"). SCIM resources are represented in JSON [RFC7159] format and MUST specify schema via the "schemas" attribute per Section 3. Attribute names MUST conform to the following ABNF rules: ATTRNAME = ALPHA *(nameChar) nameChar = "$" / "-" / "_" / DIGIT / ALPHA Figure 1: ABNF for Attribute Names The above rules (and other rules in this specification) use the "Core Rules" from ABNF; see Appendix B of [RFC5234]. Unless otherwise specified in this document, all ABNF strings are case insensitive and the character set for these strings is US-ASCII. For example, all attribute names defined by the above rule are case insensitive. When defining attribute names, it should be noted that the hyphen ("-") is not permitted in JavaScript attribute names (or in attribute names for some other languages). While there are no known issues within HTTP protocol and JSON notation, attribute names containing hyphens may need to be escaped when declaring corresponding names of JavaScript attributes.
Top   ToC   RFC7643 - Page 8

2.2. Attribute Characteristics

All attributes have a set of characteristics that describe their type and handling by a service provider; full definitions may be found in Section 7. The characteristics include: o "required", o "canonicalValues", o "caseExact", o "mutability", o "returned", o "uniqueness", and o "referenceTypes". If not otherwise stated in Section 7, SCIM attributes have the following characteristics: o "required" is "false" (i.e., not REQUIRED), o "canonicalValues": none assigned (for example, the "type" sub-attribute as described in Section 2.4), o "caseExact" is "false" (i.e., case-insensitive), o "mutability" is "readWrite" (i.e., modifiable), o "returned" is "default" (the attribute value is returned by default), o "uniqueness" is "none" (has no uniqueness enforced), and o "type" is "string" (Section 2.3.1).

2.3. Attribute Data Types

Attribute data types are derived from JSON [RFC7159]. The JSON format defines a limited set of data types; hence, where appropriate, alternate JSON representations derived from XML Schema [XML-Schema] are defined below. SCIM extensions SHOULD NOT introduce new data types.
Top   ToC   RFC7643 - Page 9
   Table 1 maps the following SCIM data types to their corresponding
   SCIM schema type and underlying JSON data type:

   +-----------+-------------+-----------------------------------------+
   | SCIM Data | SCIM Schema | JSON Type                               |
   | Type      | "type"      |                                         |
   +-----------+-------------+-----------------------------------------+
   | String    | "string"    | String per Section 7 of [RFC7159]       |
   |           |             |                                         |
   | Boolean   | "boolean"   | Value per Section 3 of [RFC7159]        |
   |           |             |                                         |
   | Decimal   | "decimal"   | Number per Section 6 of [RFC7159]       |
   |           |             |                                         |
   | Integer   | "integer"   | Number per Section 6 of [RFC7159]       |
   |           |             |                                         |
   | DateTime  | "dateTime"  | String per Section 7 of [RFC7159]       |
   |           |             |                                         |
   | Binary    | "binary"    | Binary value base64 encoded per Section |
   |           |             | 4 of [RFC4648], or with URL and         |
   |           |             | filename safe alphabet URL per Section  |
   |           |             | 5 of [RFC4648] that is passed as a JSON |
   |           |             | string per Section 7 of [RFC7159]       |
   |           |             |                                         |
   | Reference | "reference" | String per Section 7 of [RFC7159]       |
   |           |             |                                         |
   | Complex   | "complex"   | Object per Section 4 of [RFC7159]       |
   +-----------+-------------+-----------------------------------------+

              Table 1: SCIM Data Type to JSON Representation

2.3.1. String

A sequence of zero or more Unicode characters encoded using UTF-8 as per [RFC2277] and [RFC3629]. The JSON format is defined in Section 7 of [RFC7159]. An attribute with SCIM schema type "string" MAY specify a required data format. Additionally, when "canonicalValues" is specified, service providers MAY restrict accepted values to the specified values.

2.3.2. Boolean

The literal "true" or "false". The JSON format is defined in Section 3 of [RFC7159]. A boolean has no case sensitivity or uniqueness.
Top   ToC   RFC7643 - Page 10

2.3.3. Decimal

A real number with at least one digit to the left and right of the period. The JSON format is defined in Section 6 of [RFC7159]. A decimal has no case sensitivity.

2.3.4. Integer

A whole number with no fractional digits or decimal. The JSON format is defined in Section 6 of [RFC7159], with the additional constraint that the value MUST NOT contain fractional or exponent parts. An integer has no case sensitivity.

2.3.5. DateTime

A DateTime value (e.g., 2008-01-23T04:56:22Z). The attribute value MUST be encoded as a valid xsd:dateTime as specified in Section 3.3.7 of [XML-Schema] and MUST include both a date and a time. A date time format has no case sensitivity or uniqueness. Values represented in JSON format MUST conform to the XML constraints above and are represented as a JSON string per Section 7 of [RFC7159].

2.3.6. Binary

Arbitrary binary data. The attribute value MUST be base64 encoded as specified in Section 4 of [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify that base64 URL encoding be used as per Section 5 of [RFC4648]. Unless otherwise specified in the attribute definition, trailing padding characters MAY be omitted ("="). In JSON representation, the encoded values are represented as a JSON string per Section 7 of [RFC7159]. A binary is case exact and has no uniqueness.

2.3.7. Reference

A URI for a resource. A resource MAY be a SCIM resource, an external link to a resource (e.g., a photo), or an identifier such as a URN. The value MUST be the absolute or relative URI of the target resource. Relative URIs should be resolved as specified in Section 5.2 of [RFC3986]. However, the base URI for relative URI resolution MUST include all URI components and path segments up to, but not including, the Endpoint URI (the SCIM service provider root
Top   ToC   RFC7643 - Page 11
   endpoint); e.g., the base URI for a request to
   "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
   would be "https://example.com/v2/", and the relative URI for this
   resource would be "Users/2819c223-7f76-453a-919d-413861904646".

   In JSON representation, the URI value is represented as a JSON string
   per Section 7 of [RFC7159].  A reference is case exact.  A reference
   has a "referenceTypes" attribute that indicates what types of
   resources may be linked, as per Section 7 of this document.

   A reference URI MUST be to an HTTP-addressable resource.  An HTTP
   client performing a GET operation on a reference URI MUST receive the
   target resource or an appropriate HTTP response code.  A SCIM service
   provider MAY choose to enforce referential integrity for reference
   types referring to SCIM resources.

   By convention, a reference is commonly represented as a "$ref"
   sub-attribute in complex or multi-valued attributes; however, this is
   OPTIONAL.

2.3.8. Complex

A singular or multi-valued attribute whose value is a composition of one or more simple attributes. The JSON format is defined in Section 4 of [RFC7159]. The order of the component attributes is not significant. Servers and clients MUST NOT require or expect attributes to be in any specific order when an object is either generated or analyzed. A complex attribute has no uniqueness or case sensitivity. A complex attribute MUST NOT contain sub-attributes that have sub-attributes (i.e., that are complex).

2.4. Multi-Valued Attributes

Multi-valued attributes contain a list of elements using the JSON array format defined in Section 5 of [RFC7159]. Elements can be either of the following: o primitive values, or o objects with a set of sub-attributes and values, using the JSON object format defined in Section 4 of [RFC7159], in which case they SHALL be considered to be complex attributes. As with complex attributes, the order of sub-attributes is not significant. The predefined sub-attributes listed in this section can be used with multi-valued attribute objects, but these sub-attributes MUST be used with the meanings defined here.
Top   ToC   RFC7643 - Page 12
   If not otherwise defined, the default set of sub-attributes for a
   multi-valued attribute is as follows:

   type
      A label indicating the attribute's function, e.g., "work" or
      "home".

   primary
      A Boolean value indicating the 'primary' or preferred attribute
      value for this attribute, e.g., the preferred mailing address or
      the primary email address.  The primary attribute value "true"
      MUST appear no more than once.  If not specified, the value of
      "primary" SHALL be assumed to be "false".

   display
      A human-readable name, primarily used for display purposes and
      having a mutability of "immutable".

   value
      The attribute's significant value, e.g., email address, phone
      number.

   $ref
      The reference URI of a target resource, if the attribute is a
      reference.  URIs are canonicalized per Section 6.2 of [RFC3986].
      While the representation of a resource may vary in different SCIM
      protocol API versions (see Section 3.13 of [RFC7644]), URIs for
      SCIM resources with an API version SHALL be considered comparable
      to URIs without a version or with a different version.  For
      example, "https://example.com/Users/12345" is equivalent to
      "https://example.com/v2/Users/12345".

   When returning multi-valued attributes, service providers SHOULD
   canonicalize the value returned (e.g., by returning a value for the
   sub-attribute "type", such as "home" or "work") when appropriate
   (e.g., for email addresses and URLs).

   Service providers MAY return element objects with the same "value"
   sub-attribute more than once with a different "type" sub-attribute
   (e.g., the same email address may be used for work and home) but
   SHOULD NOT return the same (type, value) combination more than once
   per attribute, as this complicates processing by the client.

   When defining schema for multi-valued attributes, it is considered a
   good practice to provide a type attribute that MAY be used for the
   purpose of canonicalization of values.  In the schema definition for
   an attribute, the service provider MAY define the recommended
   canonical values (see Section 7).
Top   ToC   RFC7643 - Page 13

2.5. Unassigned and Null Values

Unassigned attributes, the null value, or an empty array (in the case of a multi-valued attribute) SHALL be considered to be equivalent in "state". Assigning an attribute with the value "null" or an empty array (in the case of multi-valued attributes) has the effect of making the attribute "unassigned". When a resource is expressed in JSON format, unassigned attributes, although they are defined in schema, MAY be omitted for compactness.


(page 13 continued on part 2)

Next Section