RFC 7643
System for Cross-domain Identity Management: Core Schema
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 SchemaAbstract
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.
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
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 ...............................................1041. 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
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.
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.
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.
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.
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.
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 Representation2.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.
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
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.
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).
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)
