RFC 7643
System for Cross-domain Identity Management: Core Schema
9. Security Considerations
9.1. Protocol
SCIM data is intended to be exchanged using the SCIM protocol. It is important when handling data to implement the security considerations outlined in Section 7 of [RFC7644].9.2. Passwords and Other Sensitive Security Data
Passwords and other attributes related to security credentials are of an extremely sensitive nature and require special handling when transmitted or stored. While the SCIM protocol uses cleartext passwords for value assignment and equality-testing purposes, password values MUST NOT be stored in cleartext form. Administrators should undertake industry best practices to protect the storage of credentials and in particular SHOULD follow recommendations outlined in Section 5.1.4.1 of [RFC6819]. These requirements include, but are not limited to, the following: o Provide injection attack countermeasures (e.g., by validating all inputs and parameters); o Credentials should not be stored in cleartext form; o Store credentials using an encrypted protection mechanism (e.g., hashing); and o Where possible, avoid passwords as the sole form of authentication, and consider using credentials that are based on asymmetric cryptography.9.3. Privacy
The SCIM core schema defines attributes that are sensitive and may be considered personally identifying information (PII). These privacy considerations should be considered for extensions as well as the schema defined in this specification. For the purposes of this specification, PII is defined as any attribute that may be used as a unique key to identify a person (e.g., "User"). Since other information may be used in combination to identify an individual, all attributes in SCIM are considered "sensitive" personal information. Consult regional jurisdictions to see if there are special considerations for the handling of personal information (e.g., PII).
Information should be shared on an as-needed basis. A SCIM client should limit information to what it believes a service provider requires, and a SCIM service provider should only accept information it needs. Clients and service providers should take into consideration that personal information is being conveyed across technical (e.g., protocol and applications), administrative (e.g., organizational, corporate), and jurisdictional boundaries. In particular, information security and privacy must be considered. Security service level agreements for the handling of these attributes are beyond the scope of this document but are to be carefully considered by implementers and deploying organizations. Please see the Privacy Considerations section of [RFC7644] for more protocol-specific considerations regarding the handling of SCIM information. SCIM defines attributes such as "id", "externalId", and SCIM resource URIs, which cause new PII to be generated; this information is important to the way that the SCIM protocol identifies and locates resources. Where possible, it is suggested that service providers take the following remediations: o Where possible, assign and bind identifiers to specific tenants and/or clients. When multiple tenants are able to reference the same resource, they should do so via separate identifiers (id or externalId). This ensures that separate domains linked to the same information cannot perform identifier correlation. o In the case of "externalId", if multiple values are supported, use access control to restrict access to the client domain that assigned the "externalId" value. o Ensure that access to data is appropriately restricted to authorized parties with a "need to know". o When persisted, ensure that the appropriate protection mechanisms are in place to restrict access by unauthorized parties, including administrators or parties with access to backup data.
10. IANA Considerations
10.1. Registration of SCIM URN Sub-namespace and SCIM Registry
IANA has added an entry to the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry and created a sub-namespace for the Registered Parameter Identifier as per [RFC3553]: "urn:ietf:params:scim". To manage this sub-namespace, IANA has created the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry, which is used to manage entries within the "urn:ietf:params:scim" namespace. The registry description is as follows: o Registry name: SCIM o Specification: this document (RFC 7643) o Repository: See Section 10.2 o Index value: See Section 10.210.2. URN Sub-namespace for SCIM
SCIM schemas and SCIM messages utilize URIs to identify the schema in use or other relevant context. This section creates and registers an IETF URN Sub-namespace for use in the SCIM specifications and future extensions.
10.2.1. Specification Template
Namespace ID: The Namespace ID "scim" has been assigned. Registration Information: Version: 1 Date: 2015-06-22 Declared registrant of the namespace: Registering organization The Internet Engineering Task Force Designated contact A designated expert will monitor the SCIM public mailing list, "scim@ietf.org". Declaration of Syntactic Structure: The Namespace Specific String (NSS) of all URNs that use the "scim" Namespace ID shall have the following structure: urn:ietf:params:scim:{type}:{name}{:other} The keywords have the following meaning: type The entity type, which is either "schemas" or "api". name A required US-ASCII string that conforms to the URN syntax requirements (see [RFC2141]) and defines a major namespace of a schema used within SCIM (e.g., "core", which is reserved for SCIM specifications). The value MAY also be an industry name or organization name. other Any US-ASCII string that conforms to the URN syntax requirements (see [RFC2141]) and defines the sub-namespace (which MAY be further broken down in namespaces delimited by colons) as needed to uniquely identify a schema.
Relevant Ancillary Documentation:
None
Identifier Uniqueness Considerations:
The designated contact shall be responsible for reviewing and
enforcing uniqueness.
Identifier Persistence Considerations:
Once a name has been allocated, it MUST NOT be reallocated for a
different purpose. The rules provided for assignments of values
within a sub-namespace MUST be constructed so that the meanings of
values cannot change. This registration mechanism is not
appropriate for naming values whose meanings may change over time.
As the SCIM specifications are updated and the SCIM protocol
version is adjusted, a new registration will be made when
significant changes are made -- for example,
"urn:ietf:params:scim:schemas:core:1.0 (externally defined, not
previously registered)" and
"urn:ietf:params:scim:schemas:core:2.0".
Process of Identifier Assignment:
Identifiers with namespace type "schema" (e.g.,
"urn:ietf:params:scim:schemas") are assigned after the review of
the assigned contact via the SCIM public mailing list,
"scim@ietf.org", as documented in Section 10.3.
Namespaces with type "api" (e.g., "urn:ietf:params:scim:api") and
"param" (e.g., "urn:ietf:params:scim:param") are reserved for
IETF-approved SCIM specifications.
Process of Identifier Resolution:
The namespace is not currently listed with a Resolution Discovery
System (RDS), but nothing about the namespace prohibits the future
definition of appropriate resolution methods or listing with an
RDS.
Rules for Lexical Equivalence:
No special considerations; the rules for lexical equivalence
specified in [RFC2141] apply.
Conformance with URN Syntax:
No special considerations.
Validation Mechanism:
None specified.
Scope:
Global.
10.3. Registering SCIM Schemas
This section defines the process for registering new SCIM schemas
with IANA in the "System for Cross-domain Identity Management (SCIM)
Schema URIs" registry (see Section 10.1). A schema URI is used as a
value in the "schemas" attribute (Section 3) for the purpose of
distinguishing extensions used in a SCIM resource.
10.3.1. Registration Procedure
The IETF has created a mailing list, scim@ietf.org, which can be used
for public discussion of SCIM schema proposals prior to registration.
Use of the mailing list is strongly encouraged. The IESG has
appointed a designated expert [RFC5226] who will monitor the
scim@ietf.org mailing list and review registrations.
Registration of new "core" schemas (e.g., in the namespace
"urn:ietf:params:scim:schemas:core") and "API" schemas (e.g., in the
namespace "urn:ietf:params:scim:api") MUST be reviewed by the
designated expert and published in an RFC. An RFC is REQUIRED for
the registration of new value data types that modify existing
properties. An RFC is also REQUIRED for registration of SCIM schema
URIs that modify SCIM schema previously documented in an existing
RFC. URNs within "urn:ietf:params:scim" but outside the above
namespaces MAY be registered with a simple review (e.g., check for
spam) by the designated expert on a first-come-first-served basis.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to scim@ietf.org and
iana@iana.org. Within two weeks, the designated expert is expected
to tell IANA and the submitter of the registration whether the
registration is approved, approved with minor changes, or rejected
with cause. When a registration is rejected with cause, it can be
resubmitted if the concerns listed in the cause are addressed.
Decisions made by the designated expert can be appealed to the IESG Applications Area Director, then to the IESG. They follow the normal appeals procedure for IESG decisions. Once the registration procedure concludes successfully, IANA creates or modifies the corresponding record in the SCIM schema registry. The completed registration template is discarded. An RFC specifying one or more new schema URIs MUST include the completed registration templates, which MAY be expanded with additional information. These completed templates are intended to go in the body of the document, not in the IANA Considerations section. The RFC SHOULD include any attributes defined.10.3.2. Schema Registration Template
A SCIM schema URI is defined by completing the following template: Schema URI: A unique URI for the SCIM schema extension. Schema Name: A descriptive name of the schema extension (e.g., "Generic Device"). Intended or Associated Resource Type: A value defining the resource type (e.g., "Device"). Purpose: A description of the purpose of the extension and/or its intended use. Single-value Attributes: A list and description of single-valued attributes defined, including complex attributes. Multi-valued Attributes: A list and description of multi-valued attributes defined, including complex attributes.
10.4. Initial SCIM Schema Registry
The IANA has populated the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry with the following registries for SCIM schema URIs, with pointers to appropriate reference documents. Note: The schema URIs listed below are broken into two lines for readability. +-----------------------------------+-----------------+-------------+ | Schema URI | Name | Reference | +-----------------------------------+-----------------+-------------+ | urn:ietf:params:scim:schemas: | User Resource | See Section | | core:2.0:User | | 4.1 | | | | | | urn:ietf:params:scim:schemas: | Enterprise User | See Section | | extension:enterprise:2.0:User | Extension | 4.3 | | | | | | urn:ietf:params:scim:schemas: | Group Resource | See Section | | core:2.0:Group | | 4.2 | +-----------------------------------+-----------------+-------------+ SCIM Schema URIs for Data Resources +-----------------------------------+-------------------+-----------+ | Schema URI | Name | Reference | +-----------------------------------+-------------------+-----------+ | urn:ietf:params:scim:schemas: | Service Provider | See | | core:2.0:ServiceProviderConfig | Configuration | Section 5 | | | Schema | | | | | | | urn:ietf:params:scim:schemas: | Resource Type | See | | core:2.0:ResourceType | Configuration | Section 6 | | | | | | urn:ietf:params:scim:schemas: | Schema | See | | core:2.0:Schema | Definitions | Section 7 | | | Schema | | +-----------------------------------+-------------------+-----------+ SCIM Server-Related Schema URIs
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, <http://www.rfc-editor.org/info/rfc4647>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>. [RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>. [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <http://www.rfc-editor.org/info/rfc6557>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>. [RFC7232] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>. [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, <http://www.rfc-editor.org/info/rfc7644>.11.2. Informative References
[ISO3166] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO 3166-1:2013, November 2013, <http://www.iso.org>. [Olson-TZ] Internet Assigned Numbers Authority, "IANA Time Zone Database", <https://www.iana.org/time-zones>. [PortableContacts] Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only", August 2008, <http://www.portablecontacts.net/draft-spec.html>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <http://www.rfc-editor.org/info/rfc2277>. [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, DOI 10.17487/RFC4512, June 2006, <http://www.rfc-editor.org/info/rfc4512>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <http://www.rfc-editor.org/info/rfc6350>. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>. [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <http://www.rfc-editor.org/info/rfc6819>. [XML-Schema] Peterson, D., Gao, S., Malhotra, A., Sperberg-McQueen, C., and H. Thompson, "XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes", April 2012, <http://www.w3.org/TR/xmlschema11-2/>.
Acknowledgements
The editor would like to acknowledge the contribution and work of the editors of draft versions of this document: Chuck Mortimore, Salesforce Patrick Harding, Ping Paul Madsen, Ping Trey Drake, UnboundID The SCIM Community would like to thank the following people for the work they've done in the research, formulation, drafting, editing, and support of this specification. Morteza Ansari (morteza.ansari@cisco.com) Sidharth Choudhury (schoudhury@salesforce.com) Samuel Erdtman (samuel@erdtman.se) Kelly Grizzle (kelly.grizzle@sailpoint.com) Chris Phillips (cjphillips@gmail.com) Erik Wahlstroem (erik.wahlstrom@nexusgroup.com) Phil Hunt (phil.hunt@yahoo.com) Special thanks to Joseph Smarr, whose excellent work on the Portable Contacts Specification [PortableContacts] provided a basis for the SCIM schema structure and text.
Authors' Addresses
Phil Hunt (editor) Oracle Corporation Email: phil.hunt@yahoo.com Kelly Grizzle SailPoint Email: kelly.grizzle@sailpoint.com Erik Wahlstroem Nexus Technology Email: erik.wahlstrom@nexusgroup.com Chuck Mortimore Salesforce.com Email: cmortimore@salesforce.com