| SCIM WG | P. Hunt |
| Internet-Draft | Oracle |
| Intended status: Informational | B. Khasnabish |
| Expires: April 02, 2013 | ZTE USA, Inc. |
| A. Nadalin | |
| Microsoft | |
| Z. Zeltsan | |
| Alcatel-Lucent | |
| October 2012 |
SCIM Use Cases
draft-zeltsan-scim-use-cases-00
This document lists the use cases of System for Cross-domain Identity Management (SCIM).
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 April 02, 2013.
Copyright (c) 2012 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.
This document describes the SCIM 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].
The following section provides the abbreviated descriptions of the use cases.
This section lists the SCIM use cases.
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:
Post-conditions:
Requirements:
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:
Post-conditions:
Requirements:
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:
Post-conditions:
Bob has received the requested service from an application running on AnotherCSP without having to authenticate to that application explicitly.
Requirements:
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).
Pre-conditions:
Post-conditions:
Requirements:
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 through a federation protocol (e.g., WS-Federation, SAML, OAuth), 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.
The attributes of the user change later in directory service A. For example, the attributes might change if the user changes their name, has their account disabled, or terminates their relationship with directory service A. The directory service A then wishes to notify relying party web site B of these changes, as relying party B might (or might not) have a cache of those attributes, and if the relying party B were aware of these changes to their cached copy, would potentially cause a state change in relying party B. (E.g., if the user's account were disabled in A, then the relying party B might wish to also change their access control policies as well).
Pre-conditions:
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 parties.
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 example, the attributes might change if the user changes their name, has their account disabled, or terminates their relationship with directory service A. Furthermore, other resources and their attributes might also change. The directory service A then wishes to notify relying party web site B of these changes, as relying party B might (or might not) have a cache of those attributes, and if the relying party B were aware of these changes to their cached copy, 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.
Pre-conditions:
Post-conditions:
Service A is able to notify 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.
TBD
This Internet Draft includes no request to IANA.
TBD
| [I-D.ietf-scim-api] | Drake, T, Mortimore, C, Ansari, M, Grizzle, K and E Wahlstroem, "System for Cross-Domain Identity Management:Protocol", Internet-Draft draft-ietf-scim-api-00, August 2012. |
| [I-D.ietf-scim-core-schema] | Mortimore, C, Harding, P, Madsen, P and T Drake, "System for Cross-Domain Identity Management: Core Schema", Internet-Draft draft-ietf-scim-core-schema-00, August 2012. |