idnits 2.17.1 draft-ietf-scim-use-cases-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2015) is 3331 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-scim-api-15 == Outdated reference: A later version (-22) exists of draft-ietf-scim-core-schema-17 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SCIM WG P. Hunt 3 Internet-Draft Oracle 4 Intended status: Informational B. Khasnabish 5 Expires: September 7, 2015 ZTE USA,Inc. 6 A. Nadalin 7 Microsoft 8 K. Li 9 Alibaba Group 10 Z. Zeltsan 11 Individual 12 March 6, 2015 14 SCIM Use Cases 15 draft-ietf-scim-use-cases-04 17 Abstract 19 This document lists the user scenarios and use cases of System for 20 Cross-domain Identity Management (SCIM). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 7, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Background & Context . . . . . . . . . . . . . . . . . . 4 60 2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . 4 61 2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3. Modes & Flows . . . . . . . . . . . . . . . . . . . . 6 64 2.2.4. Bulk & Batch Operational Semantics . . . . . . . . . 7 65 2.3. Cloud Service Provider to Cloud Service Provider Flows 66 (CSP->CSP) . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3.1. CSP->CSP - Create Identity (Push) . . . . . . . . . . 7 68 2.3.2. CSP->CSP - Update Identity (Push) . . . . . . . . . . 7 69 2.3.3. CSP->CSP - Delete Identity (Push) . . . . . . . . . . 8 70 2.3.4. CSP->CSP - SSO Trigger (Push) . . . . . . . . . . . . 8 71 2.3.5. CSP->CSP - SSO Trigger (Pull) . . . . . . . . . . . . 8 72 2.3.6. CSP->CSP - Password Reset (Push) . . . . . . . . . . 9 73 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 74 Flows(ECS->CSP) . . . . . . . . . . . . . . . . . . . . . 9 75 2.4.1. ECS->CSP - Create Identity (Push) . . . . . . . . . . 9 76 2.4.2. ECS ->CSP - Update Identity (Push) . . . . . . . . . 9 77 2.4.3. ECS ->CSP - Delete Identity (Push) . . . . . . . . . 9 78 2.4.4. ECS ->CSP - SSO Pull . . . . . . . . . . . . . . . . 10 79 3. SCIM use cases . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. Change of the ownership of a file . . . . . . . . . . . . 10 81 3.2. Migration of the identities . . . . . . . . . . . . . . . 11 82 3.3. Single Sign-On (SSO) Service . . . . . . . . . . . . . . 12 83 3.4. Provisioning of the user accounts for a Community of 84 Interest (CoI) . . . . . . . . . . . . . . . . . . . . . 13 85 3.5. Transfer of attributes to a relying party web site . . . 14 86 3.6. Change notification . . . . . . . . . . . . . . . . . . . 15 87 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 88 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 7.2. Informative References . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 This document describes the SCIM scenarios and use cases. It also 98 provides a list of the requirements derived from the use cases. The 99 document's objective is to help with understanding of the design and 100 applicability of SCIM schema [I-D.ietf-scim-core-schema] and SCIM 101 protocol [I-D.ietf-scim-api]. 103 The following section provides the abbreviated descriptions of the 104 scenarios and use cases. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119] when they 111 appear in ALL CAPS. These words may also appear in this document in 112 lower case as plain English words, absent their normative meanings. 114 Here is a list of acronyms and abbreviations used in this document: 116 o COI: Community Of Interest 118 o CRM: Customer Relationship Management 120 o CRUD: Create Read Update Delete 122 o CSP: Cloud Service Provider 124 o CSU: Cloud Service User 126 o ECS: Enterprise Cloud Subscriber 128 o IaaS: Infrastructure as a Service 130 o JIT: Just In Time 132 o PaaS: Platform as a Service 134 o SaaS: Software as a Service 136 o SAML: Security Assertion Markup Language 138 o SCIM: System for Cross-domain Identity Management 140 o SSO: Single-Sign On 142 2. SCIM User Scenarios 144 2.1. Background & Context 146 The System for Cross-domain Identity Management (SCIM) specification 147 is designed to make managing user identity in cloud based 148 applications and services easier. The specification suite seeks to 149 build upon experience with existing schemas and deployments, placing 150 specific emphasis on simplicity of development and integration, while 151 applying existing authentication, authorization, and privacy models. 152 It's intent is to reduce the cost and complexity of user management 153 operations by providing a common user schema and extension model, as 154 well as binding documents to provide patterns for exchanging this 155 schema using standard protocols. In essence, make it fast, cheap, 156 and easy to move users in to, out of, and around the cloud. 158 The SCIM scenarios are overview user stories designed to help clarify 159 the intended scope of the SCIM effort. 161 2.2. Model Concepts 163 2.2.1. Triggers 165 Quite simply, triggers are actions or activities that start SCIM 166 flows. Triggers may not be relevant at the protocol or the schema, 167 they really serve to help identify the type or activity that resulted 168 in a SCIM protocol exchange. Triggers make use of the traditional 169 provisioning C.R.U.D (Create Read Update & Delete) operations but add 170 additional use case contexts like "SSO" (Single-Sign On) as it is 171 designed to capture a class of use case that makes sense to the actor 172 requesting it rather than to describe a protocol operation. 174 o Create SCIM Identity Resource - Service On-boarding Trigger: A 175 "create SCIM identity resource" trigger is a service on-boarding 176 activity in which a business action such as a new hire or new 177 service subscription is initiated by one of the SCIM Actors. In 178 the protocol itself, service on-boarding may well be implemented 179 via the same resource PUT method as a service change. This is 180 particular to the implementation, and not to the use cases that 181 drive that implementation. 183 o Update SCIM Identity Resource - Service Change Trigger: An "update 184 SCIM identity resource" trigger is a service change activity as a 185 result of an identity moving or changing its service level. An 186 "update SCIM identity" trigger might be the result of a change in 187 a service subscription level or a change to key identity data used 188 to denote a service subscription level. Password changes are 189 specifically called out from other more general identity attribute 190 changes as they are considered to have specific use case 191 differences. 193 o Delete SCIM Identity Resource - Service Termination Trigger: A 194 "delete SCIM identity resource" trigger represents a specific and 195 deliberate action to remove an identity from a given SCIM service 196 point. At this stage it is unclear if the SCIM protocol needs to 197 identify separate protocol exchange for a service suspension 198 actions. This may be relevant as target services usually 199 differentiate between these result and may require separate 200 resource representations as a result. 202 o Single-Sign On (SSO) Trigger - Real-time Service Access Request: A 203 "Single-Sign On" trigger is a special class of activity in which a 204 Create or Update trigger is initiated during an SSO operational 205 flow. The implication here is that as the result of a real-time 206 service access request by the end user (SSO), defined SCIM 207 protocol exchanges can be used to initiate SCIM resource CRUD 208 somewhere in the service cloud. 210 2.2.2. Actors 212 Actors are the operating parties that take part in both sides of a 213 SCIM protocol exchange, and help identify the source of a given 214 Trigger. So far, we have identified the following SCIM Actors: 216 o Cloud Service Provider (CSP): A CSP is the entity operating a 217 given cloud service. In a SaaS scenario this is simply the 218 application provider. In an IaaS or PaaS scenario, the CSP may be 219 the underlying IaaS/PaaS infrastructure provider or the owner of 220 the application running on that platform. In all cases, the CSP 221 is the thing that holds the identity information being operated 222 upon. Put another way, the CSP really is the service that the 223 end-end user interacts with. 225 o Enterprise Cloud Subscriber (ECS): An ECS represents a middle-tier 226 of aggregation for related identity records. In one of our sample 227 enterprise SaaS scenarios, the ECS is "FooBar.Inc" that subscribes 228 to a cloud based CRM service service "SaaS-CRM.Inc" (the CSP) for 229 all of its sales staff. The actual Cloud Service Users (CSUs) are 230 the FooBar.Inc. sales staff. The ECS actor is identified to help 231 capture use cases in which a single entity is given administrative 232 responsibility for other identity accounts. SCIM may not address 233 the configuration and setup of an ECS within the CSP, but it does 234 address use cases in which SCIM identity resources are grouped 235 together and administers as part of some broader agreement or 236 operational exchange. 238 o Cloud Service User (CSU): A CSU represents the real cloud service 239 end user - the "person logging into and using the cloud service". 240 As described above, and ECS will typically own or manage multiple 241 CSU identities where as the CSU represents the FooBar.Inc. 242 employee using the cloud service to manage their CRM process. 244 +---------------------+ 245 | Cloud Service | 246 | Provider (CSP) | 247 +---------------------+ 248 | 249 +--------------------------------+ 250 | | 251 v v 252 +----------------+ +----------------+ 253 |Enterprise Cloud| |Enterprise Cloud| 254 |Subscriber (ECS)| |Subscriber (ECS | 255 +----------------+ +----------------+ 256 | | 257 +----------------+ +----------------+ 258 | | | | 259 v v v v 260 +-------------+ +-------------+ +-------------+ +-------------+ 261 |Cloud Service| |Cloud Service| |Cloud Service| |Cloud Service| 262 | User (CSU) | | User (CSU) | | User (CSU) | | User (CSU) | 263 +-------------+ +-------------+ +-------------+ +-------------+ 265 Figure 1: SCIM Actors 267 2.2.3. Modes & Flows 269 Modes identify the functional intent of a data-flow initiated in a 270 SCIM scenario. The modes identified so far are 'push' and 'pull' 271 referring to the fact of pushing data to, or pulling data from an 272 authoritative identity data store. 274 In the SCIM scenarios, Modes are often used in the context of a flow 275 between two Actors. For example, one might refer to a Cloud-to-Cloud 276 Pull exchange. Here one Cloud Service Provider (CSP) is pulling 277 identity information from another CSP. Commonly referenced flows 278 are: 280 o Cloud Service Provider to Cloud Service Provider (CSP->CSP) 282 o Enterprise Cloud Subscriber to Cloud Service Provider (ECS-CSP) 284 Modes & flows simply help us understand what is taking place; they 285 are likely to be technically meaningless at the protocol level, but 286 again they help the reader follow the SCIM scenarios and apply them 287 to real world use cases. 289 2.2.4. Bulk & Batch Operational Semantics 291 It is assumed that each of the triggers action outlined in this 292 document may be part of the larger bulk or batch operation. 293 Individual SCIM actions should be able to be collected together to 294 create single protocol exchanges. 296 The initial focus of SCIM scenarios is on identifying base flows and 297 single operations. The specific complexity of full bulk and batch 298 operations is left to a later version of the scenarios or to the main 299 specification. 301 2.3. Cloud Service Provider to Cloud Service Provider Flows (CSP->CSP) 303 These scenarios represent flows between two Cloud Service Providers 304 (CSPs). It is assumed that each CSP maintains an Identity Data Store 305 for its Cloud Service Users (CSUs). These scenarios address various 306 joiner, mover, leaver and JIT triggers, resulting in push and pull 307 data exchanges between the CSPs. 309 2.3.1. CSP->CSP - Create Identity (Push) 311 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 312 agreement in place that requires the exchange of Cloud Service User 313 (CSU) accounts. CSP-1 receives a Create Identity trigger action from 314 its Enterprise Cloud Subscriber (ECS-1). CSP-1 creates a local user 315 account for the new CSU. CSP-1 then pushes the new CSU joiner push 316 request down-stream to CSU-2 and gets confirmation that the account 317 was successfully created. After receiving the confirmation from CSP- 318 2, CSP-1 sends an acknowledgement to the requesting ECS. 320 2.3.2. CSP->CSP - Update Identity (Push) 322 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 323 agreement in place that requires the exchange of Cloud Service User 324 (CSU) accounts. The Enterprise Cloud Subscriber (ECS-1) has already 325 created an account with CSP-1 and supplied a critical attribute 326 "department" that is used by CSP-1 to drive service options. CSP-1 327 then receives an Update Identity trigger action from its Enterprise 328 Cloud Subscriber (ECS). CSP-1 updates its local directory account 329 with the new department value. CSP-1 then initiates a separate SCIM 330 protocol exchange to push the mover change request down-stream to 331 CSP-2. After receiving the confirmation from CSP-2, CSP-1 sends an 332 acknowledgment to ECS-1. 334 2.3.3. CSP->CSP - Delete Identity (Push) 336 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 337 agreement in place that requires the exchange of Cloud Service User 338 (CSU) accounts. CSP-1 receives a Delete Identity trigger action from 339 its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local 340 directory account for the specified CSU account. CSP-1 then pushes a 341 termination request for the specified CSU account down-stream to 342 CSP-2 and gets confirmation that the account was successfully 343 removed. After receiving the confirmation from CSP-2, CSP-1 344 finalizes the deletion operation and sends an acknowledgment to the 345 requesting ECS. 347 This use case highlights how different CSPs may implement different 348 operational semantics behind the same SCIM operation. Note CSP-1 349 suspends the account representation for its service where as CPS-2 350 implements a true delete operation. 352 2.3.4. CSP->CSP - SSO Trigger (Push) 354 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 355 agreement in place that requires the exchange of Cloud Service User 356 (CSU) accounts. However, rather than pre-provisioning accounts from 357 CSP-1 to CSP-2, CSP-1 waits for a service access request from the end 358 Cloud Service User (CSU-1) before issuing account creation details to 359 CSP-2. When the CSU completes a SSO transaction from CSP-1 to CSP-2, 360 CSP-2 then creates an account for the CSU based on information pushed 361 to it from CSP-1. 363 At the protocol level, this class of scenarios may result in the use 364 of common protocol exchange patters between CSP-1 & CSP-2. 366 2.3.5. CSP->CSP - SSO Trigger (Pull) 368 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 369 agreement in place that requires the exchange of Cloud Service User 370 (CSU) accounts. However, rather than pre-provisioning accounts from 371 CSP-1 to CSP-2, CSP-2 waits for a service access request from the 372 Cloud Service User (CSU-1) before initiating a Pull request to gather 373 information about the CSU sufficient to create a local account. 375 At the protocol level, this class of scenarios may result in the use 376 of common protocol exchange patterns between CSP-2 & CSP-1. 378 2.3.6. CSP->CSP - Password Reset (Push) 380 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 381 agreement in place that requires the exchange of Cloud Service User 382 (CSU) accounts. CSP-1 wants to change the password for a specific 383 Cloud Service User (CSU-1). CSP-1 sends a request to CSP-2 to reset 384 the password value for CSU-1. 386 At the protocol level, this scenario may result in the same protocol 387 exchange as any other attribute change request. 389 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 390 Flows(ECS->CSP) 392 These scenarios represent flows between an Enterprise Cloud 393 Subscriber (ECS) and a Cloud Service Providers (CSP). It is assumed 394 that both the ECS and the CSP maintains an LDAP service for the 395 relevant Cloud Service Users (CSUs). These scenarios address various 396 joiner, mover, leaver and JIT triggers, resulting in push and pull 397 data exchanges between the ECS and the CSP. 399 Many of these scenarios are very similar to those defined in the 400 Cloud Service Provider to Cloud Service Provider section above. They 401 are identified separately here so that we may explore any differences 402 and might emerge. 404 2.4.1. ECS->CSP - Create Identity (Push) 406 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 407 service with a Cloud Service Provider (CSP-1) that requires the 408 sharing of various Cloud Service User (CSU) accounts. A new user 409 joins ECS-1 and so ECS-1 pushes an account creation request to CSP-1, 410 supplying all required base SCIM schema attribute values and 411 additional extended SCIM schema values as required. 413 2.4.2. ECS ->CSP - Update Identity (Push) 415 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 416 service with Cloud Service Provider (CSP-1) that drives service 417 definition from a key account schema attribute called Department. 418 ECS-1 wishes to move a given CSU from Department A to Department B 419 and so it pushes an attribute update request to the CSP. 421 2.4.3. ECS ->CSP - Delete Identity (Push) 423 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 424 service with a Cloud Service Provider (CSP-1). Upon termination of 425 one of its employees' employment agreement, ECS-1 sends a suspend 426 account request to CSP-1 (Figure 1.4.3-1). One week later the ECS 427 wishes to complete the process by fully removing the Cloud Service 428 User (CSU) account and so it sends a terminate account request to 429 CSP-1. 431 2.4.4. ECS ->CSP - SSO Pull 433 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 434 service with a Cloud Service Provider (CSP-1). No accounts are 435 created or exchanged in advance. However, rather than pre- 436 provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service 437 access request from the Cloud Service User (CSU-1) under the control 438 domain of ECS-1, before issuing an account Pull request to ECS-1. 440 3. SCIM use cases 442 This section lists the SCIM use cases. 444 3.1. Change of the ownership of a file 446 Description: 448 Bob - an employee of the company SomeEnterprise - creates a file, 449 which is located at the cloud provided by SomeCSP. After Bob leaves 450 SomeEnterprise, SomeCSP on a request from SomeEnterprise terminates 451 Bob's rights to the file and transfers his former rights to Bill - 452 another employee of SomeEnterprise. 454 Pre-conditions: 456 o SomeCSP is a cloud service provider for SomeEnterprise 458 o With permission of SomeEnterprise, Bob had created a file at the 459 cloud provided by SomeCSP 461 o Bob has left SomeEnterprise 463 o SomeEnterprise terminates Bob's rights to the file and, possibly, 464 decommissions Bob's identity 466 o SomeEnterprise communicates the changes to Bob's rights to SomeCSP 468 o SomeCSP enforces the changes made by SomeEnterprise 470 o SomeEnterprise requests SomeCSP to transfer Bob's former rights to 471 Bill 473 Post-conditions: 475 o Bob does not have the rights to the file at the cloud provided by 476 SomeCSP 478 o Bill has the rights to the file that Bob had 480 Requirements: 482 o SomeEnterprise can securely communicate to SomeCSP all changes 483 regarding its employee's identity 485 o SomeCSP can enforce the requested changes 487 o SomeCSP shall be able to log all changes regarding a 488 SomeEnterprise employee's identity 490 o The logs should be secure and available for auditing 492 3.2. Migration of the identities 494 Description: 496 A company SomeEnterprise runs an application ManageThem that relies 497 on the identity information about its employees (e.g., identifiers, 498 attributes). The identity information is stored at the cloud 499 provided by SomeCSP. SomeEnterprise has decided to move identity 500 information to the cloud of a different provider - AnotherCSP. In 501 addition, SomeEnterprise has purchased a second application 502 ManageThemMore, which also relies on the identity information. 503 SomeEnterprise is able to move identity information to AnotherCSP 504 without changing the format of identity information. The application 505 ManageThemMore is able to use the identity information. 507 Pre-conditions: 509 o SomeCSP is a cloud service provider for SomeEnterprise 511 o SomeCSP has a known attribute name and value for the Enterprise 512 used for managing and transferring data 514 o AnotherCSP is a new cloud service provider for SomeEnterprise 516 o All involved cloud service providers and applications support the 517 same standard specifying the format for and actions on the user 518 (e.g., employee) identity information 520 Post-conditions: 522 o SomeEnterprise has moved its employees' identity information from 523 SomeCSP to AnotherCSP without making any changes to representation 524 of identity information 526 o Application ManageThemMore is able to use the identity information 528 Requirements: 530 o SomeEnterprise, the applications ManageThem and ManageThemMore, 531 the providers SomeCSP and AnotherCSP support a common standard for 532 identity information, which specifies the following: 534 * Format (or schema) for representing user identity information 536 * Interfaces and protocol for managing user identity information 538 o Cloud providers shall be able to log all actions related to 539 SomeEnterprise employees' identities 541 o The logs should be secure and available for auditing 543 3.3. Single Sign-On (SSO) Service 545 Description: 547 Bob has an account with application hosted by a cloud service 548 provider SomeCSP. SomeCSP has federated its user identities with a 549 cloud service provider AnotherCSP. Bob requests a service from an 550 application running on AnotherCSP. The application running on 551 AnotherCSP, relying on Bob's authentication by SomeCSP and using 552 identity information provided by SomeCSP, serves Bob's request. 554 Pre-conditions: 556 o Bob's identity information is stored on SomeCSP 558 o SomeCSP and AnotherCSP have established trust and federated their 559 user identities 561 o SomeCSP is able to authenticate Bob 563 o SomeCSP is able to securely provide the authentication results to 564 AnotherCSP 566 o SomeCSP is able to securely provide Bob's identity information 567 (e.g., attributes) to AnotherCSP 569 o AnotherCSP is able to verify information provided by SomeCSP 570 o SomeCSP is able to process the identity information received from 571 AnotherCSP 573 Post-conditions: 575 Bob has received the requested service from an application running on 576 AnotherCSP without having to authenticate to that application 577 explicitly. 579 Requirements: 581 o Bob must have an account with SomeCSP 583 o SomeCSP and AnotherCSP must establish trust and federate their 584 user identities 586 o SomeCSP must be able to authenticate Bob 588 o SomeCSP must be able to securely provide the authentication 589 results to AnotherCSP 591 o SomeCSP must be able to securely provide Bob's identity 592 information (e.g., attributes) to AnotherCSP 594 o AnotherCSP must be able to verify the identity information 595 provided by SomeCSP 597 o SomeCSP must be able to process the identity information received 598 from AnotherCSP 600 o SomeCSP and AnotherCSP must log information generated by Bob's 601 actions according to their policies and the trust agreement 602 between them 604 3.4. Provisioning of the user accounts for a Community of Interest 605 (CoI) 607 Description: 609 Organization YourHR provides Human Resources (HR) services to a 610 Community of Interest (CoI) YourCoI. The HR services are offered as 611 Software-as-a-Service (SaaS) on public and private clouds. YourCoI's 612 offices are located all over the world. Their Information Technology 613 (IT) systems may be composed of the combinations of the applications 614 running on Private and Public clouds along with the traditional IT 615 systems. The local YourCoI offices are responsible for collecting 616 personal information(i.e. user identities and attributes). YourHR 617 services provide means for provisioning and distributing the employee 618 identity information across all YourCoI offices. YourHR also enables 619 the individual users (e.g., employees) to manage their personal 620 information that they are responsible for (e.g., update of an address 621 or a telephone number). 623 Pre-conditions: 625 o YourCoI has a complex infrastructure composed of the large number 626 of local offices that rely on the diverse IT systems 628 o YourCoI has contracted YourHR to provide the HR services 630 o Each local office has a right to establish a personal account for 631 an employee 633 Post-conditions: 635 o All personal accounts are globally available to any authorized 636 user or application across the YourCoI system through the services 637 provided by YourHR 639 o The employees have ability to manage the part of personal 640 information that is in their responsibility 642 Requirements: 644 o YourHR must ensure that the personal information generated by the 645 local offices is timely available in a globally-accessible 646 database. 648 o Identity management of the personal data must be protected against 649 unauthorised access and remain confidential to only authorised 650 parties. 652 o All operation with identity data must be securely logged. 654 o The logs should be available for auditing. 656 3.5. Transfer of attributes to a relying party web site 658 Description: 660 An end user has an account in a directory service A with one or more 661 attributes. That user then visits relying party web site B, and the 662 user authorizes the transfer of data via authorization protocols 663 (e.g. OAuth, SAML), so selected attributes of the user are 664 transferred from the user's account in directory service A to the web 665 site B at the time of the user's first visit to that site. 667 Pre-conditions: 669 o User has an account in a directory service A 671 o User has one or more attributes 673 o User visits web site of a relying party B 675 Post-conditions: 677 Selected attributes of the user are transferred from the user's 678 account in directory service A to the web site B at the time of the 679 user's first visit to that site. 681 Requirements: 683 Relying parties have to be aware of changes to their cached copy, as 684 these would potentially cause a state change in other relying 685 parties. 687 A maximum period should be set for the relying party to cache the 688 information. 690 3.6. Change notification 692 Description: 694 An end user has an account in a directory service A with one or more 695 attributes. That user then visits relying party web site B. Relying 696 party web site B queries directory service A for attributes 697 associated with that user, and related resources. 699 The attributes of the user change later in directory service A. For 700 example, the attributes might change if the user changes their name, 701 has their account disabled, or terminates their relationship with 702 directory service A. Furthermore, other resources and their 703 attributes might also change. The directory service A then wishes to 704 notify relying party web site B of these changes, as relying party B 705 might (or might not) have a cache of those attributes, and if the 706 relying party B were aware of these changes to their cached copy, 707 would potentially cause a state change in relying party B. 709 The volume of changes, however, might be substantial, and only some 710 of the changes may be of interest to relying party B, so directory 711 service A does not wish to "push" all the changes to B. Instead, 712 directory service A wishes to notify B that there are changes 713 potentially of interest, such that B can at an appropriate time 714 subsequently contact directory service A and retrieve just the subset 715 of changes of interest to B. 717 Note that the user must authorize the directory A service to transfer 718 data to the web site, and the user must authorize the directory A 719 service to notify the web site. 721 Pre-conditions: 723 o User has an account in a directory service A 725 o User has one or more attributes 727 o User visits relying party web site B 729 o The resource being updated is at the web site 731 Post-conditions: 733 Service A is able to notify B that there are changes potentially of 734 interest. 736 Requirements: 738 B must be able at an appropriate time to subsequently contact 739 directory service A and retrieve just the subset of changes of 740 interest to B. 742 4. Security considerations 744 SCIM resources (e.g., Users and Groups) can contain sensitive 745 information. Therefore, authentication and authorization must be 746 guaranteed for the SCIM operations. 748 Also, private information of the SCIM resources must be kept 749 confidential and protected. 751 5. IANA considerations 753 This Internet Draft includes no request to IANA. 755 6. Acknowledgements 757 Authors would like to thank Ray Counterman, Richard Fiekowsky and 758 Bert Greevenbosch for their reviews and comments. 760 Also thanks to Darran Rolls and Patrick Harding, the SCIM user 761 scenarios section is taken from them. 763 7. References 765 7.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 7.2. Informative References 772 [I-D.ietf-scim-api] 773 Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C. 774 Mortimore, "System for Cross-Domain Identity Management: 775 Protocol", draft-ietf-scim-api-15 (work in progress), 776 February 2015. 778 [I-D.ietf-scim-core-schema] 779 Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore, 780 "System for Cross-Domain Identity Management: Core 781 Schema", draft-ietf-scim-core-schema-17 (work in 782 progress), March 2015. 784 Authors' Addresses 786 Phil Hunt 787 Oracle 789 Email: phil.hunt@oracle.com 791 Bhumip Khasnabish 792 ZTE USA,Inc. 794 Phone: +001-781-752-8003 795 Email: vumip1@gmail.com, bhumip.khasnabish@zteusa.com 797 Anthony Nadalin 798 Microsoft 800 Email: tonynad@microsoft.com 801 Kepeng LI 802 Alibaba Group 803 Wenyixi Road, Yuhang District 804 Hangzhou, Zhejiang 311121 805 China 807 Email: kepeng.lkp@alibaba-inc.com 809 Zachary Zeltsan 810 Individual 812 Email: Zachary.Zeltsan@gmail.com