Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7644

System for Cross-domain Identity Management: Protocol

Pages: 89
Proposed Standard
Errata
Part 4 of 4 – Pages 76 to 89
First   Prev   None

Top   ToC   RFC7644 - Page 76   prevText

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.
Top   ToC   RFC7644 - 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 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.
Top   ToC   RFC7644 - 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 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].
Top   ToC   RFC7644 - 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 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.
Top   ToC   RFC7644 - 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"], "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.
Top   ToC   RFC7644 - 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 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
Top   ToC   RFC7644 - 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

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)
Top   ToC   RFC7644 - 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
      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
Top   ToC   RFC7644 - 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   ToC   RFC7644 - 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, <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>.
Top   ToC   RFC7644 - Page 86
   [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>.
Top   ToC   RFC7644 - Page 87

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>.
Top   ToC   RFC7644 - 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,
              <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)
Top   ToC   RFC7644 - Page 89

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