tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7643

Proposed STD
Pages: 104
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SCIM

System for Cross-domain Identity Management: Core Schema

Part 1 of 4, p. 1 to 13
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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 RFC Part