--- 1/draft-ietf-scim-use-cases-01.txt 2014-06-18 02:14:27.642019422 -0700 +++ 2/draft-ietf-scim-use-cases-02.txt 2014-06-18 02:14:27.678020281 -0700 @@ -1,25 +1,25 @@ SCIM WG P. Hunt Internet-Draft Oracle Intended status: Informational B. Khasnabish -Expires: September 5, 2014 ZTE USA,Inc. +Expires: December 20, 2014 ZTE USA,Inc. A. Nadalin Microsoft K. Li Huawei Z. Zeltsan Individual - March 4, 2014 + June 18, 2014 SCIM Use Cases - draft-ietf-scim-use-cases-01 + draft-ietf-scim-use-cases-02 Abstract This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -27,21 +27,21 @@ 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 5, 2014. + This Internet-Draft will expire on December 20, 2014. Copyright Notice Copyright (c) 2014 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 @@ -80,22 +80,22 @@ 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.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 3.6. Change notification . . . . . . . . . . . . . . . . . . . 15 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document describes the SCIM 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]. @@ -157,61 +157,62 @@ The SCIM scenarios are overview user stories designed to help clarify the intended scope of the SCIM effort. 2.2. Model Concepts 2.2.1. Triggers Quite simply, triggers are actions or activities that start SCIM flows. Triggers may not be relevant at the protocol or the schema, - they really serve to help identity the type or activity that resulted + they really serve to help identify the type or activity that resulted in a SCIM protocol exchange. Triggers make use of the traditional provisioning C.R.U.D (Create Read Update & Delete) operations but add - additional use case contexts like "SSO" as it is designed to capture - a class of use case that makes sense to the actor requesting it - rather than to describe a protocol operation. + additional use case contexts like "SSO" (Single-Sign On) as it is + designed to capture a class of use case that makes sense to the actor + requesting it rather than to describe a protocol operation. o Create SCIM Identity Resource - Service On-boarding Trigger: A - create SCIM resource trigger is a service on-boarding activity in - which a business action such as a new hire or new service - subscription is initiated by one of the SCIM Actors. In the - protocol itself, service on-boarding may well be implemented via - the same resource PUT method as a service change. This is - particular to the implementation not to the use cases that drive - that implementation. + "create SCIM identity resource" trigger is a service on-boarding + activity in which a business action such as a new hire or new + service subscription is initiated by one of the SCIM Actors. In + the protocol itself, service on-boarding may well be implemented + via the same resource PUT method as a service change. This is + particular to the implementation, and not to the use cases that + drive that implementation. - o Update SCIM Identity Resource - Service Change Trigger: An Update - SCIM resource trigger is a service change activity as a result of - an identity moving or changing its service level. An Update - Identity trigger might be the result of a change in a service - subscription level or a change to key identity data used to denote - a service subscription level. Password changes are specifically - called out from other more general identity attribute changes as - they are considered to have specific use case differences. + o Update SCIM Identity Resource - Service Change Trigger: An "update + SCIM identity resource" trigger is a service change activity as a + result of an identity moving or changing its service level. An + "update SCIM identity" trigger might be the result of a change in + a service subscription level or a change to key identity data used + to denote a service subscription level. Password changes are + specifically called out from other more general identity attribute + changes as they are considered to have specific use case + differences. o Delete SCIM Identity Resource - Service Termination Trigger: A - delete SCIM resource trigger represents a specific and deliberate - action to remove an identity from a given SCIM service point. At - this stage it is unclear if the SCIM protocol needs to identify - separate protocol exchange for a service suspension actions. This - may be relevant as target services usually differentiate between - these result and may require separate resource representations as - a result. + "delete SCIM identity resource" trigger represents a specific and + deliberate action to remove an identity from a given SCIM service + point. At this stage it is unclear if the SCIM protocol needs to + identify separate protocol exchange for a service suspension + actions. This may be relevant as target services usually + differentiate between these result and may require separate + resource representations as a result. o Single-Sign On (SSO) Trigger - Real-time Service Access Request: A - SSO trigger is a special class of activity in which a Create or - Update trigger is initiated during an SSO operational flow. The - implication here is that as the result of a real-time service - access request by the end user (SSO), defined SCIM protocol - exchanges can be used to initiate SCIM resource CRUD somewhere in - the service cloud. + "Single-Sign On" trigger is a special class of activity in which a + Create or Update trigger is initiated during an SSO operational + flow. The implication here is that as the result of a real-time + service access request by the end user (SSO), defined SCIM + protocol exchanges can be used to initiate SCIM resource CRUD + somewhere in the service cloud. 2.2.2. Actors Actors are the operating parties that take part in both sides of a SCIM protocol exchange, and help identify the source of a given Trigger. So far, we have identified the following SCIM Actors: o Cloud Service Provider (CSP): A CSP is the entity operating a given cloud service. In a SaaS scenario this is simply the application provider. In an IaaS or PaaS scenario, the CSP may be @@ -220,33 +221,32 @@ is the thing that holds the identity information being operated upon. Put another way, the CSP really is the service that the end-end user interacts with. o Enterprise Cloud Subscriber (ECS): An ECS represents a middle-tier of aggregation for related identity records. In one of our sample enterprise SaaS scenarios, the ECS is "FooBar.Inc" that subscribes to a cloud based CRM service service "SaaS-CRM.Inc" (the CSP) for all of its sales staff. The actual Cloud Service Users (CSUs) are the FooBar.Inc. sales staff. The ECS actor is identified to help - capture use cases in which a single entitle is given - administrative responsibility for other identity accounts. SCIM - may not address the configuration and setup of an ECS within the - CSP, but it does address use cases in which SCIM identity - resources are grouped together and administers as part of some - broader agreement or operational exchange. + capture use cases in which a single entity is given administrative + responsibility for other identity accounts. SCIM may not address + the configuration and setup of an ECS within the CSP, but it does + address use cases in which SCIM identity resources are grouped + together and administers as part of some broader agreement or + operational exchange. o Cloud Service User (CSU): A CSU represents the real cloud service - end-end user - the "person logging into and using the cloud - service". As described above, and ECS will typically own or - manage multiple CSU identities where as the CSU represents the - FooBar.Inc. employee using the cloud service to manage their CRM - process. + end user - the "person logging into and using the cloud service". + As described above, and ECS will typically own or manage multiple + CSU identities where as the CSU represents the FooBar.Inc. + employee using the cloud service to manage their CRM process. +---------------------+ | Cloud Service | | Provider (CSP) | +---------------------+ | +--------------------------------+ | | v v +----------------+ +----------------+ @@ -273,24 +273,25 @@ In the SCIM scenarios, Modes are often used in the context of a flow between two Actors. For example, one might refer to a Cloud-to-Cloud Pull exchange. Here one Cloud Service Provider (CSP) is pulling identity information from another CSP. Commonly referenced flows are: o Cloud Service Provider to Cloud Service Provider (CSP->CSP) o Enterprise Cloud Subscriber to Cloud Service Provider (ECS-CSP) + Modes & flows simply help us understand what is taking place; they are likely to be technically meaningless at the protocol level, but again they help the reader follow the SCIM scenarios and apply them - to real work use cases. + to real world use cases. 2.2.4. Bulk & Batch Operational Semantics It is assumed that each of the triggers action outlined in this document may be part of the larger bulk or batch operation. Individual SCIM actions should be able to be collected together to create single protocol exchanges. The initial focus of SCIM scenarios is on identifying base flows and single operations. The specific complexity of full bulk and batch @@ -306,22 +307,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 @@ -332,22 +333,23 @@ 2.3.3. CSP->CSP - Delete 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 Delete Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local directory account for the specified CSU account. CSP-1 then pushes a termination request for the specified CSU account down-stream to CSP-2 and gets confirmation that the account was successfully - removed. After receiving the confirmation from CSP-2, CSP-1 sends an - acknowledgment to the requesting ECS. + removed. After receiving the confirmation from CSP-2, CSP-1 + finalizes the deletion operation and sends an acknowledgment to the + requesting ECS. This use case highlights how different CSPs may implement different operational semantics behind the same SCIM operation. Note CSP-1 suspends the account representation for its service where as CPS-2 implements a true delete operation. 2.3.4. CSP->CSP - SSO Trigger (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 @@ -426,21 +428,21 @@ User (CSU) account and so it sends a terminate account request to CSP-1. 2.4.4. ECS ->CSP - SSO Pull In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1). No accounts are created or exchanged in advance. However, rather than pre- provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service access request from the Cloud Service User (CSU-1) under the control - domain of ECS-1, before issuing an account Pull request to CSP-1. + domain of ECS-1, before issuing an account Pull request to ECS-1. 3. SCIM use cases This section lists the SCIM use cases. 3.1. Change of the ownership of a file Description: Bob - an employee of the company SomeEnterprise - creates a file, @@ -466,21 +468,21 @@ o SomeCSP enforces the changes made by SomeEnterprise o SomeEnterprise requests SomeCSP to transfer Bob's former rights to Bill Post-conditions: o Bob does not have the rights to the file at the cloud provided by SomeCSP - o Bill has the rights to the file that Bob had 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 o SomeCSP can enforce the requested changes o SomeCSP shall be able to log all changes regarding a SomeEnterprise employee's identity @@ -603,27 +605,27 @@ (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 (IT) systems may be composed of the combinations of the applications running on Private and Public clouds along with the traditional IT - systems. The local YourCoI offices are responsible for establishing - personal information and (i.e., setting the 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). + systems. The local YourCoI offices are responsible for collecting + 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 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 @@ -634,27 +636,29 @@ user or application across the YourCoI system through the services provided by YourHR o The employees have ability to manage the part of personal 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 + database. - o Identity management of the personal data must be secure + o Identity management of the personal data must be protected against + unauthorised access and remain confidential to only authorised + parties. - o All operation with identity data must be securely logged + o All operation with identity data must be securely logged. - o The logs should be available for auditing + o The logs should be available for auditing. 3.5. Transfer of attributes to a relying party web site 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, 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 @@ -673,20 +677,23 @@ 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 parties. + 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. The attributes of the user change later in directory service A. For @@ -727,22 +734,26 @@ 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. 4. Security considerations - Authorization and authentication must be guaranteed for the SCIM - operations. + SCIM resources (e.g., Users and Groups) can contain sensitive + information. Therefore, authentication and authorization must be + guaranteed for the SCIM operations. + + Also, private information of the SCIM resources must be kept + confidential and protected. 5. IANA considerations This Internet Draft includes no request to IANA. 6. Acknowledgements Authors would like to thank Ray Counterman, Richard Fiekowsky and Bert Greevenbosch for their reviews and comments. @@ -752,30 +763,30 @@ 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. 7.2. Informative References [I-D.ietf-scim-api] - Grizzle, K., Hunt, P., Ansari, M., Wahlstroem, E., and C. + Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-Domain Identity - Management:Protocol", draft-ietf-scim-api-03 (work in - progress), February 2014. + Management:Protocol", draft-ietf-scim-api-05 (work in + progress), May 2014. [I-D.ietf-scim-core-schema] Grizzle, K., Hunt, P., Wahlstroem, E., and C. Mortimore, "System for Cross-Domain Identity Management: Core - Schema", draft-ietf-scim-core-schema-03 (work in - progress), February 2014. + Schema", draft-ietf-scim-core-schema-05 (work in + progress), May 2014. Authors' Addresses Phil Hunt Oracle Email: phil.hunt@oracle.com Bhumip Khasnabish ZTE USA,Inc.