--- 1/draft-ietf-scim-use-cases-05.txt 2015-04-14 10:14:51.612630753 -0700 +++ 2/draft-ietf-scim-use-cases-06.txt 2015-04-14 10:14:51.652631725 -0700 @@ -1,106 +1,105 @@ SCIM WG P. Hunt Internet-Draft Oracle Intended status: Informational B. Khasnabish -Expires: September 25, 2015 ZTE USA,Inc. +Expires: October 15, 2015 ZTE (TX) Inc. A. Nadalin Microsoft K. LI, Ed. Alibaba Group Z. Zeltsan Individual - March 24, 2015 + April 13, 2015 - System for Cross-domain Identity Management (SCIM) Definitions, - Overview, and Flows - draft-ietf-scim-use-cases-05 + SCIM Definitions, Overview, and Flows + draft-ietf-scim-use-cases-06 Abstract This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's models and flows, and includes user scenarios, use cases, and requirements. -Status of This Memo +Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 25, 2015. + This Internet-Draft will expire on October 15, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Background & Context . . . . . . . . . . . . . . . . . . 4 - 2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . 4 - 2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Background & Context . . . . . . . . . . . . . . . . . . . 4 + 2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Modes & Flows . . . . . . . . . . . . . . . . . . . . 6 - 2.2.4. Bulk & Batch Operational Semantics . . . . . . . . . 7 + 2.2.4. Bulk & Batch Operational Semantics . . . . . . . . . . 7 2.3. Cloud Service Provider to Cloud Service Provider Flows - (CSP->CSP) . . . . . . . . . . . . . . . . . . . . . . . 7 + (CSP->CSP) . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. CSP->CSP - Create Identity (Push) . . . . . . . . . . 7 2.3.2. CSP->CSP - Update Identity (Push) . . . . . . . . . . 7 2.3.3. CSP->CSP - Delete Identity (Push) . . . . . . . . . . 8 2.3.4. CSP->CSP - SSO Trigger (Push) . . . . . . . . . . . . 8 2.3.5. CSP->CSP - SSO Trigger (Pull) . . . . . . . . . . . . 8 - 2.3.6. CSP->CSP - Password Reset (Push) . . . . . . . . . . 9 + 2.3.6. CSP->CSP - Password Reset (Push) . . . . . . . . . . . 8 2.4. Enterprise Cloud Subscriber to Cloud Service Provider Flows(ECS->CSP) . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. ECS->CSP - Create Identity (Push) . . . . . . . . . . 9 - 2.4.2. ECS ->CSP - Update Identity (Push) . . . . . . . . . 9 - 2.4.3. ECS ->CSP - Delete Identity (Push) . . . . . . . . . 9 - 2.4.4. ECS ->CSP - SSO Pull . . . . . . . . . . . . . . . . 10 - 3. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.2. ECS ->CSP - Update Identity (Push) . . . . . . . . . . 9 + 2.4.3. ECS ->CSP - Delete Identity (Push) . . . . . . . . . . 9 + 2.4.4. ECS ->CSP - SSO Pull . . . . . . . . . . . . . . . . . 10 + 3. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Change of the ownership of a file . . . . . . . . . . . . 10 3.2. Migration of the identities . . . . . . . . . . . . . . . 11 - 3.3. Single Sign-On (SSO) Service . . . . . . . . . . . . . . 12 + 3.3. Single Sign-On (SSO) Service . . . . . . . . . . . . . . . 12 3.4. Provisioning of the user accounts for a Community of - Interest (CoI) . . . . . . . . . . . . . . . . . . . . . 13 - 3.5. Transfer of attributes to a relying party web site . . . 14 + Interest (CoI) . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5. Transfer of attributes to a relying party web site . . . . 14 3.6. Change notification . . . . . . . . . . . . . . . . . . . 15 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 - 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 7.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document provides the SCIM definitions, models, flows, scenarios and use cases. It also provides a list of the requirements derived from the use cases. The document's objective is to help with understanding of the design and applicability of SCIM schema [I-D.ietf-scim-core-schema] and SCIM protocol [I-D.ietf-scim-api]. 1.1. Terminology @@ -307,22 +306,22 @@ data exchanges between the CSPs. 2.3.1. CSP->CSP - Create Identity (Push) In this scenario two CSPs (CSP-1 & CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. CSP-1 receives a Create Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 creates a local user account for the new CSU. CSP-1 then pushes the new CSU joiner push request down-stream to CSU-2 and gets confirmation that the account - was successfully created. After receiving the confirmation from CSP- - 2, CSP-1 sends an acknowledgement to the requesting ECS. + was successfully created. After receiving the confirmation from + CSP-2, CSP-1 sends an acknowledgement to the requesting ECS. 2.3.2. CSP->CSP - Update Identity (Push) In this scenario two CSPs (CSP-1 & CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. The Enterprise Cloud Subscriber (ECS-1) has already created an account with CSP-1 and supplied a critical attribute "department" that is used by CSP-1 to drive service options. CSP-1 then receives an Update Identity trigger action from its Enterprise Cloud Subscriber (ECS). CSP-1 updates its local directory account @@ -446,167 +445,170 @@ Description: Bob - an employee of the company SomeEnterprise - creates a file, which is located at the cloud provided by SomeCSP. After Bob leaves SomeEnterprise, SomeCSP on a request from SomeEnterprise terminates Bob's rights to the file and transfers his former rights to Bill - another employee of SomeEnterprise. Pre-conditions: - o SomeCSP is a cloud service provider for SomeEnterprise + o SomeCSP is a cloud service provider for SomeEnterprise. o With permission of SomeEnterprise, Bob had created a file at the - cloud provided by SomeCSP + cloud provided by SomeCSP. - o Bob has left SomeEnterprise + o Bob has left SomeEnterprise. o SomeEnterprise terminates Bob's rights to the file and, possibly, - decommissions Bob's identity + decommissions Bob's identity. - o SomeEnterprise communicates the changes to Bob's rights to SomeCSP + o SomeEnterprise communicates the changes to Bob's rights to + SomeCSP. - o SomeCSP enforces the changes made by SomeEnterprise + o SomeCSP enforces the changes made by SomeEnterprise. o SomeEnterprise requests SomeCSP to transfer Bob's former rights to - Bill + Bill. Post-conditions: o Bob does not have the rights to the file at the cloud provided by - SomeCSP + SomeCSP. - o Bill has the rights to the file that Bob had + o Bill has the rights to the file that Bob had. Requirements: o SomeEnterprise can securely communicate to SomeCSP all changes - regarding its employee's identity + regarding its employee's identity. - o SomeCSP can enforce the requested changes + o SomeCSP can enforce the requested changes. o SomeCSP shall be able to log all changes regarding a - SomeEnterprise employee's identity + SomeEnterprise employee's identity. - o The logs should be secure and available for auditing + o The logs should be secure and available for auditing. 3.2. Migration of the identities Description: A company SomeEnterprise runs an application ManageThem that relies on the identity information about its employees (e.g., identifiers, attributes). The identity information is stored at the cloud provided by SomeCSP. SomeEnterprise has decided to move identity information to the cloud of a different provider - AnotherCSP. In addition, SomeEnterprise has purchased a second application ManageThemMore, which also relies on the identity information. SomeEnterprise is able to move identity information to AnotherCSP without changing the format of identity information. The application ManageThemMore is able to use the identity information. Pre-conditions: - o SomeCSP is a cloud service provider for SomeEnterprise + o SomeCSP is a cloud service provider for SomeEnterprise. o SomeCSP has a known attribute name and value for the Enterprise - used for managing and transferring data + used for managing and transferring data. - o AnotherCSP is a new cloud service provider for SomeEnterprise + o AnotherCSP is a new cloud service provider for SomeEnterprise. o All involved cloud service providers and applications support the same standard specifying the format for and actions on the user - (e.g., employee) identity information + (e.g., employee) identity information. Post-conditions: o SomeEnterprise has moved its employees' identity information from SomeCSP to AnotherCSP without making any changes to representation - of identity information + of identity information. - o Application ManageThemMore is able to use the identity information + o Application ManageThemMore is able to use the identity + information. Requirements: o SomeEnterprise, the applications ManageThem and ManageThemMore, the providers SomeCSP and AnotherCSP support a common standard for identity information, which specifies the following: * Format (or schema) for representing user identity information * Interfaces and protocol for managing user identity information o Cloud providers shall be able to log all actions related to - SomeEnterprise employees' identities + SomeEnterprise employees' identities. - o The logs should be secure and available for auditing + o The logs should be secure and available for auditing. 3.3. Single Sign-On (SSO) Service Description: Bob has an account with application hosted by a cloud service provider SomeCSP. SomeCSP has federated its user identities with a cloud service provider AnotherCSP. Bob requests a service from an application running on AnotherCSP. The application running on AnotherCSP, relying on Bob's authentication by SomeCSP and using identity information provided by SomeCSP, serves Bob's request. Pre-conditions: - o Bob's identity information is stored on SomeCSP + o Bob's identity information is stored on SomeCSP. o SomeCSP and AnotherCSP have established trust and federated their - user identities + user identities. - o SomeCSP is able to authenticate Bob + o SomeCSP is able to authenticate Bob. o SomeCSP is able to securely provide the authentication results to - AnotherCSP + AnotherCSP. o SomeCSP is able to securely provide Bob's identity information - (e.g., attributes) to AnotherCSP + (e.g., attributes) to AnotherCSP. + + o AnotherCSP is able to verify information provided by SomeCSP. - o AnotherCSP is able to verify information provided by SomeCSP o SomeCSP is able to process the identity information received from - AnotherCSP + AnotherCSP. Post-conditions: Bob has received the requested service from an application running on AnotherCSP without having to authenticate to that application explicitly. Requirements: - o Bob must have an account with SomeCSP + o Bob must have an account with SomeCSP. o SomeCSP and AnotherCSP must establish trust and federate their - user identities + user identities. - o SomeCSP must be able to authenticate Bob + o SomeCSP must be able to authenticate Bob. o SomeCSP must be able to securely provide the authentication - results to AnotherCSP + results to AnotherCSP. o SomeCSP must be able to securely provide Bob's identity - information (e.g., attributes) to AnotherCSP + information (e.g., attributes) to AnotherCSP. o AnotherCSP must be able to verify the identity information - provided by SomeCSP + provided by SomeCSP. o SomeCSP must be able to process the identity information received - from AnotherCSP + from AnotherCSP. o SomeCSP and AnotherCSP must log information generated by Bob's actions according to their policies and the trust agreement - between them + between them. 3.4. Provisioning of the user accounts for a Community of Interest (CoI) Description: Organization YourHR provides Human Resources (HR) services to a Community of Interest (CoI) YourCoI. The HR services are offered as Software-as-a-Service (SaaS) on public and private clouds. YourCoI's offices are located all over the world. Their Information Technology @@ -616,35 +618,35 @@ personal information(i.e. user identities and attributes). YourHR services provide means for provisioning and distributing the employee identity information across all YourCoI offices. YourHR also enables the individual users (e.g., employees) to manage their personal information that they are responsible for (e.g., update of an address or a telephone number). Pre-conditions: o YourCoI has a complex infrastructure composed of the large number - of local offices that rely on the diverse IT systems + of local offices that rely on the diverse IT systems. - o YourCoI has contracted YourHR to provide the HR services + o YourCoI has contracted YourHR to provide the HR services. o Each local office has a right to establish a personal account for - an employee + an employee. Post-conditions: o All personal accounts are globally available to any authorized user or application across the YourCoI system through the services - provided by YourHR + provided by YourHR. o The employees have ability to manage the part of personal - information that is in their responsibility + information that is in their responsibility. Requirements: o YourHR must ensure that the personal information generated by the local offices is timely available in a globally-accessible database. o Identity management of the personal data must be protected against unauthorised access and remain confidential to only authorised parties. @@ -659,39 +661,47 @@ An end user has an account in a directory service A with one or more attributes. That user then visits relying party web site B, and the user authorizes the transfer of data via authorization protocols (e.g. OAuth, SAML), so selected attributes of the user are transferred from the user's account in directory service A to the web site B at the time of the user's first visit to that site. Pre-conditions: - o User has an account in a directory service A + o User has an account in a directory service A. - o User has one or more attributes + o User has one or more attributes. - o User visits web site of a relying party B + o User visits web site of a relying party B. Post-conditions: Selected attributes of the user are transferred from the user's account in directory service A to the web site B at the time of the user's first visit to that site. Requirements: - Relying parties have to be aware of changes to their cached copy, as - these would potentially cause a state change in other relying + o Relying party B must be able to authenticate the end user. + + o Relying party B must be able to securely provide the + authentication results to directory service A. + + o Directory service A must be able to securely provide end user's + identity information (e.g., attributes) to relying party B. + + o Relying parties have to be aware of changes to their cached copy, + as these would potentially cause a state change in other relying parties. - A maximum period should be set for the relying party to cache the + o A maximum period should be set for the relying party to cache the information. 3.6. Change notification Description: An end user has an account in a directory service A with one or more attributes. That user then visits relying party web site B. Relying party web site B queries directory service A for attributes associated with that user, and related resources. @@ -707,68 +717,77 @@ would potentially cause a state change in relying party B. The volume of changes, however, might be substantial, and only some of the changes may be of interest to relying party B, so directory service A does not wish to "push" all the changes to B. Instead, directory service A wishes to notify B that there are changes potentially of interest, such that B can at an appropriate time subsequently contact directory service A and retrieve just the subset of changes of interest to B. - Note that the user must authorize the directory A service to transfer - data to the web site, and the user must authorize the directory A - service to notify the web site. + Note that the user must authorize the directory service A to transfer + data to the web site, and the user must authorize the directory + service A to notify the web site. Pre-conditions: - o User has an account in a directory service A + o User has an account in a directory service A. - o User has one or more attributes + o User has one or more attributes. - o User visits relying party web site B + o User visits relying party web site B. - o The resource being updated is at the web site + o The resource being updated is at the web site. Post-conditions: - Service A is able to notify B that there are changes potentially of - interest. + Directory service A is able to notify relying party B that there are + changes potentially of interest. Requirements: - B must be able at an appropriate time to subsequently contact - directory service A and retrieve just the subset of changes of - interest to B. + o Relying party B must be able to authenticate the end user. + + o Relying party B must be able to securely provide the + authentication results to directory service A. + + o Directory service A must be able to securely provide end user's + changed identity information (e.g., attributes) to relying party + B. + + o Relying party B must be able at an appropriate time to + subsequently contact directory service A and retrieve just the + subset of changes of interest to relying party B. 4. Security considerations Authentication and authorization must be guaranteed for the SCIM - operations, to ensure that only authenticated entity can perform the - SCIM requests and the requested SCIM operations are authorized. + operations, to ensure that only authenticated entities can perform + the SCIM requests and the requested SCIM operations are authorized. SCIM resources (e.g., Users and Groups) can contain sensitive information. Thus, data confidentiality MUST be guaranteed at the transport layer. Detailed security considerations are specified in section 7 of SCIM protocol [I-D.ietf-scim-api] and section 9 of SCIM schema [I-D.ietf-scim-core-schema]. 5. IANA considerations This Internet Draft includes no request to IANA. 6. Acknowledgements Authors would like to thank Ray Counterman, Richard Fiekowsky, Bert - Greevenbosch, Barry Leiba, Kelly Grizzle, Dapeng Liu and Jun Li for - their reviews and comments. + Greevenbosch, Barry Leiba, Kelly Grizzle, Magnus Nystrom, Dapeng Liu + and Jun Li for their reviews and comments. Also thanks to Darran Rolls and Patrick Harding, the SCIM user scenarios section is taken from them. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -788,24 +807,29 @@ progress), March 2015. Authors' Addresses Phil Hunt Oracle Email: phil.hunt@oracle.com Bhumip Khasnabish - ZTE USA,Inc. + ZTE (TX) Inc. + 55 Madison Ave, Suite 302 + Morristown, New Jersey 07960 + USA Phone: +001-781-752-8003 - Email: vumip1@gmail.com, bhumip.khasnabish@zteusa.com + Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com + URI: http://tinyurl.com/bhumip/ + Anthony Nadalin Microsoft Email: tonynad@microsoft.com Kepeng LI (editor) Alibaba Group Wenyixi Road, Yuhang District Hangzhou, Zhejiang 311121 China