RFC 7644
System for Cross-domain Identity Management: Protocol
5. Preparation and Comparison of Internationalized Strings
To increase the likelihood that the input and comparison of usernames and passwords will work in ways that make sense for typical users throughout the world, there are rules for preparing, enforcing, and comparing internationalized strings that represent usernames and passwords. Before comparing or evaluating the uniqueness of a "userName" or "password" attribute, service providers MUST use the preparation, enforcement, and comparison of internationalized strings (PRECIS) preparation and comparison rules described in Sections 3 and 4, respectively, of [RFC7613], which is based on the PRECIS framework specification [RFC7564]. See Section 3.4 of [RFC7613] for discussion on "Case Mapping vs. Case Preparation" regarding "userName" attributes.6. Multi-Tenancy
A single service provider may expose the SCIM protocol to multiple clients. Depending on the nature of the service, the clients may have authority to access and alter resources initially created by other clients. Alternatively, clients may expect to access disjoint sets of resources and may expect that their resources are inaccessible to other clients. These scenarios are called "multi-tenancy", where each client is understood to be or represent a "tenant" of the service provider. Clients may also be multi-tenanted. The following common cases may occur: 1. All clients share all resources (no tenancy). 2. Each single client creates and accesses a private subset of resources (1 client:1 Tenant). 3. Sets of clients share sets of resources (M clients:1 Tenant). 4. One client can create and access several private subsets of resources (1 client:M Tenants). Service providers may implement any subset of the above cases. Multi-tenancy is OPTIONAL. The SCIM protocol does not define a scheme for multi-tenancy.
The SCIM protocol does not prescribe the mechanisms whereby clients
and service providers interact for the following:
o Registering or provisioning Tenants
o Associating a subset of clients with a subset of the Tenants
o Indicating which tenant is associated with the data in a request
or response, or indicating which Tenant is the subject of a query
6.1. Associating Clients to Tenants
The service provider MAY use one of the authentication mechanisms
discussed in Section 2 to determine the identity of the client and
thus infer the associated Tenant.
For implementations where a client is associated with more than one
Tenant, the service provider MAY use one of the three methods below
for explicit specification of the Tenant.
If any of these methods of allowing the client to explicitly specify
the Tenant are employed, the service provider should ensure that
access controls are in place to prevent or allow cross-tenant use
cases.
The service provider should consider precedence in cases where a
client may explicitly specify a Tenant while being implicitly
associated with a different Tenant.
In all of these methods, the {tenant_id} is a unique identifier for
the Tenant as defined by the service provider.
o A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/
Users".
o A sub-domain: "https://{tenant_id}.example.com/v2/Groups".
o An HTTP header: The service provider may recognize a {tenant_id}
provided by the client in an HTTP header as the indicator of the
desired target Tenant.
6.2. SCIM Identifiers with Multiple Tenants
Considerations for a multi-tenant implementation: o The service provider may choose to implement SCIM ids that are unique across all resources for all Tenants, but this is not required. o The externalId, defined by the client, is required to be unique ONLY within the resources associated with the associated Tenant.7. Security Considerations
7.1. HTTP Considerations
The SCIM protocol layers on top of HTTP and is thus subject to the security considerations of HTTP (Section 9 of [RFC7230]) and its related specifications. As stated in Section 2.7.1 of [RFC7230], a SCIM client MUST NOT generate the "userinfo" (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message, as userinfo and its "@" delimiter are now disallowed in HTTP.7.2. TLS Support Considerations
SCIM resources (e.g., Users and Groups) contain sensitive information, including passwords. Therefore, SCIM clients and service providers MUST require the use of a transport-layer security mechanism when communicating with SCIM service providers. The SCIM service provider MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server identity check, per [RFC6125]. Implementation security considerations for TLS can be found in [RFC7525].7.3. Authorization Token Considerations
When using authorization tokens such as those issued by OAuth 2.0 [RFC6749], implementers MUST take into account threats and countermeasures as documented in Section 8 of [RFC7521].
7.4. Bearer Token and Cookie Considerations
Since the possession of a bearer token or cookie MAY authorize the holder to potentially read, modify, or delete resources, bearer tokens and cookies MUST contain sufficient entropy to prevent a random guessing attack; for example, see Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819]. As with all SCIM communications, bearer tokens and HTTP cookies MUST be exchanged using TLS. Bearer tokens MUST have a limited lifetime that can be determined directly or indirectly (e.g., by checking with a validation service) by the service provider. By expiring tokens, clients are forced to obtain a new token (which usually involves re-authentication) for continued authorized access. For example, in OAuth 2.0, a client MAY use OAuth token refresh to obtain a new bearer token after authenticating to an authorization server. See Section 6 of [RFC6749]. As with bearer tokens, an HTTP cookie SHOULD last no longer than the lifetime of a browser session. An expiry time should be set that limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. Implementations supporting OAuth bearer tokens need to factor in security considerations of this authorization method [RFC7521]. Since security is only as good as the weakest link, implementers also need to consider authentication choices coupled with OAuth bearer tokens. The security considerations of the default authentication method for OAuth bearer tokens, HTTP Basic, are well documented in [HTTP-BASIC-AUTH]; therefore, implementers are encouraged to use stronger authentication methods. Designating the specific methods of authentication and authorization is out of scope for SCIM; however, this information is provided as a resource to implementers.7.5. Privacy Considerations
7.5.1. Personal Information
The SCIM Core Schema specification [RFC7643] defines attributes that may contain personally identifying information as well as other sensitive personal data. The privacy considerations in the Security Considerations section of [RFC7643] MUST be considered.
7.5.2. Disclosure of Sensitive Information in URIs
As mentioned in Section 9.4 of [RFC7231], SCIM clients requesting information using query filters that use HTTP GET SHOULD give consideration to the information content of the filters and whether or not their exposure in a URI would represent a breach of security or confidentiality through leakage in web browsers or server logs. This is particularly true for information that is legally considered "personally identifiable information" or is otherwise restricted by privacy laws. In these situations, to ensure maximum security and confidentiality, clients SHOULD query using HTTP POST (see Section 3.4.3). Servers that receive HTTP GET requests using filters that contain sensitive or confidential personal information SHOULD respond with HTTP status code 403 to indicate that the operation is forbidden. A "scimType" error code of "sensitive" may be returned to indicate that the request must be submitted using POST. The following is a non-normative example: HTTP/1.1 403 Forbidden { "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "detail": "Query filter involving 'name' is restricted or confidential", "scimType": "sensitive", "status": "404" }7.6. Anonymous Requests
If a SCIM service provider accepts anonymous requests such as SCIM resource creation requests (via HTTP POST), appropriate security measures should be put in place to prevent or limit exposure to attacks. The following countermeasures MAY be used: o Try to authenticate web user interface components that formulate the SCIM creation request. While the end-user may be anonymous, the web user interface component often has its own way to authenticate to the SCIM service provider (e.g., has an OAuth client credential [RFC6749]), and the web user interface component may implement its own measures (e.g., the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)) to ensure that a legitimate request is being made. o Limit the number of requests that any particular client MAY make in a period of time.
o For User resources, default newly created resources with an
"active" setting of "false", and use a secondary confirmation
process (e.g., email confirmation) to ensure that the resource
created is real.
7.7. Secure Storage and Handling of Sensitive Data
An attacker may obtain valid username/password combinations from the
SCIM service provider's underlying database by gaining access to the
database and/or launching injection attacks. This could lead to
unintended disclosure of username/password combinations. The impact
may extend beyond the domain of the SCIM service provider if the data
was provisioned from other domains.
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
recommendations 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.
As outlined in Section 5.1.4.2 of [RFC6819], administrators SHOULD
take countermeasures such as the following, to prevent online attacks
on secrets:
o Utilize a secure password policy in order to increase user
password entropy, which will in turn hinder online attacks and
password guessing;
o Mitigate attacks on passwords by locking respective accounts that
have a number of failed attempts;
o Use "tar pit" techniques by temporarily locking a respective
account and delaying responses for a certain duration. The
duration may increase with the number of failed attempts; and
o Use authentication systems that use CAPTCHAs and other factors for
authenticating users, to further reduce the possibility of
automated attacks.
Service providers SHOULD define an access control model that
differentiates between individual client applications and their
specific need to access information, and any User self-service rights
to review and update personal profile information. This may include
OAuth 2.0 delegation profiles that allow client systems to act on
behalf of users with their permission.
7.8. Case-Insensitive Comparison and International Languages
When comparing Unicode strings such as those in query filters or
testing for uniqueness of usernames and passwords, strings MUST be
appropriately prepared before comparison. See Section 5.
8. IANA Considerations
8.1. Media Type Registration
To: ietf-types@iana.org
Subject: Registration of media type application/scim+json
Type name: application
Subtype name: scim+json
Required parameters: none
Optional parameters: none
Encoding considerations: 8bit
Security considerations: See Section 7 of this document (RFC 7644)
Interoperability considerations: The "application/scim+json" media
type is intended to identify JSON structure data that conforms to
the SCIM protocol and schema specifications. Older versions of
SCIM are known to informally use "application/json".
Published specification: this document (RFC 7644)
Applications that use this media type: It is expected that
applications that use this type may be special-purpose
applications intended for inter-domain provisioning. Clients may
also be applications (e.g., mobile applications) that need to use
SCIM for self-registration of user accounts. SCIM services may be
offered by web applications that offer support for standards-based
provisioning or may be a dedicated SCIM service provider such as a
"cloud directory". Content may be treated as equivalent to the
"application/json" type for the purpose of displaying in web
browsers.
Additional information:
Magic number(s):
File extension(s): .scim .scm
Macintosh file type code(s):
Person & email address to contact for further information: SCIM
mailing list "<scim@ietf.org>"
Intended usage: COMMON* (see restrictions)
Restrictions on usage: For most client types, it is sufficient to
recognize the content as equivalent to "application/json".
Applications intending to use the SCIM protocol SHOULD use the
"application/scim+json" media type.
Author: Phil Hunt
Change controller: IETF
8.2. Registering URIs for SCIM Messages
As per the "SCIM Schema URIs for Data Resources" registry established by [RFC7643], the following defines and registers the SCIM protocol request/response JSON schema URN identifier prefix of "urn:ietf:params:scim:api:messages:2.0", which is part of the URN sub-namespace for SCIM. There is no specific associated resource type. +---------------------------------+-----------------+---------------+ | Schema URI | Name | Reference | +---------------------------------+-----------------+---------------+ | urn:ietf:params:scim:api: | List/Query | See Section | | messages:2.0:ListResponse | Response | 3.4.2 | | | | | | urn:ietf:params:scim:api: | POST Query | See Section | | messages:2.0:SearchRequest | Request | 3.4.3 | | | | | | urn:ietf:params:scim:api: | PATCH Operation | See Section | | messages:2.0:PatchOp | | 3.5.2 | | | | | | urn:ietf:params:scim:api: | Bulk Operations | See Section | | messages:2.0:BulkRequest | Request | 3.7 | | | | | | urn:ietf:params:scim:api: | Bulk Operations | See Section | | messages:2.0:BulkResponse | Response | 3.7 | | | | | | urn:ietf:params:scim:api: | Error Response | See Section | | messages:2.0:Error | | 3.12 | +---------------------------------+-----------------+---------------+ Table 10: SCIM Schema URIs for Data Resources
9. References
9.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>. [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>. [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>. [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>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <http://www.rfc-editor.org/info/rfc5789>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>. [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>. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[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>. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [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>. [RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>. [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015, <http://www.rfc-editor.org/info/rfc7538>. [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>. [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, <http://www.rfc-editor.org/info/rfc7643>.
9.2. Informative References
[HTTP-BASIC-AUTH] Reschke, J., "The 'Basic' HTTP Authentication Scheme", Work in Progress, draft-ietf-httpauth-basicauth-update-07, February 2015. [OAuth-PoP-Arch] Hunt, P., Ed., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Work in Progress, draft-ietf-oauth-pop-architecture-02, July 2015. [OpenSearch] Clinton, D., "OpenSearch Protocol 1.1, Draft 5", December 2005, <http://www.opensearch.org/Specifications/ OpenSearch/1.1>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>. [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>. [RFC6902] Bryan, P., Ed., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, <http://www.rfc-editor.org/info/rfc6902>. [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <http://www.rfc-editor.org/info/rfc7486>. [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <http://www.rfc-editor.org/info/rfc7521>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>. [XML-Schema] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.Acknowledgements
The editor would like to acknowledge the contribution and work of the editors of draft versions of this document: Trey Drake, UnboundID Chuck Mortimore, Salesforce The editor would like to thank the participants in the SCIM working group for their support of this specification.Contributors
Samuel Erdtman (samuel@erdtman.se) Patrick Harding (pharding@pingidentity.com)
Authors' Addresses
Phil Hunt (editor) Oracle Corporation Email: phil.hunt@yahoo.com Kelly Grizzle SailPoint Email: kelly.grizzle@sailpoint.com Morteza Ansari Cisco Email: morteza.ansari@cisco.com Erik Wahlstroem Nexus Technology Email: erik.wahlstrom@nexusgroup.com Chuck Mortimore Salesforce.com Email: cmortimore@salesforce.com