Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 7644


System for Cross-domain Identity Management: Protocol

Part 4 of 4, p. 76 to 89
Prev RFC Part


prevText      Top      Up      ToC       Page 76 
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"

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

   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.

Top      Up      ToC       Page 77 
   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

   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: "{tenant_id}/v2/

   o  A sub-domain: "https://{tenant_id}".

   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.

Top      Up      ToC       Page 78 
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

   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].

Top      Up      ToC       Page 79 
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 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

   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.

Top      Up      ToC       Page 80 
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"],
          "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.

Top      Up      ToC       Page 81 
   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 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 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

Top      Up      ToC       Page 82 
   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


   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)

Top      Up      ToC       Page 83 
   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

   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 "<>"

   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

Top      Up      ToC       Page 84 
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

Top      Up      ToC       Page 85 
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,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
              ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
              November 2003, <>.

   [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,

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5789]  Dusseault, L. and J. Snell, "PATCH Method for HTTP",
              RFC 5789, DOI 10.17487/RFC5789, March 2010,

   [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, <>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,

Top      Up      ToC       Page 86 
   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
              March 2014, <>.

   [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,

   [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,

   [RFC7232]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Conditional Requests",
              RFC 7232, DOI 10.17487/RFC7232, June 2014,

   [RFC7235]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,

   [RFC7538]  Reschke, J., "The Hypertext Transfer Protocol Status
              Code 308 (Permanent Redirect)", RFC 7538,
              DOI 10.17487/RFC7538, April 2015,

   [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,

   [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, <>.

Top      Up      ToC       Page 87 
9.2.  Informative References

              Reschke, J., "The 'Basic' HTTP Authentication Scheme",
              Work in Progress, draft-ietf-httpauth-basicauth-update-07,
              February 2015.

              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.

              Clinton, D., "OpenSearch Protocol 1.1, Draft 5",
              December 2005, <

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,

   [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,

   [RFC6902]  Bryan, P., Ed., and M. Nottingham, Ed., "JavaScript Object
              Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902,
              April 2013, <>.

   [RFC7486]  Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
              Bound Authentication (HOBA)", RFC 7486,
              DOI 10.17487/RFC7486, March 2015,

   [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, <>.

   [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, <>.

Top      Up      ToC       Page 88 
   [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,

              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C Recommendation, October 2004,


   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.


   Samuel Erdtman (

   Patrick Harding (

Top      Up      ToC       Page 89 
Authors' Addresses

   Phil Hunt (editor)
   Oracle Corporation


   Kelly Grizzle


   Morteza Ansari


   Erik Wahlstroem
   Nexus Technology


   Chuck Mortimore