Skip to content

System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements

Internet Engineering Task Force (IETF)                        K. LI, Ed.  
Request for Comments: 7642                                 Alibaba Group  
Category: Informational                                          P. Hunt  
ISSN: 2070-1721                                                   Oracle  
                                                           B. Khasnabish  
                                                           ZTE (TX) Inc.  
                                                              A. Nadalin  
                                                               Microsoft  
                                                              Z. Zeltsan  
                                                              Individual  
                                                          September 2015

Abstract

本書は、System for Cross-domain Identity Management（SCIM）の定義と概要を提供する。SCIM の概念、モデル、フローを整理し、利用シナリオ、ユースケース、要求事項を含む。

Status of This Memo

本書は Internet Standards Track の仕様ではなく、情報提供を目的として公開される。

本書は Internet Engineering Task Force（IETF）の成果物である。IETF コミュニティの合意を反映している。公開レビューを受け、Internet Engineering Steering Group（IESG）により公開が承認された。IESG により承認されたすべての文書が、いかなるレベルの Internet Standard の候補になるわけではない。RFC 5741 の Section 2 を参照。

本書の現在の状況、正誤表（errata）、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7642 から取得できる。

Copyright (c) 2015 IETF Trust および文書著者として特定された者。無断複製・転載を禁ずる。

本書は、発行日に有効な BCP 78 および IETF Trust の「IETF Documents に関する法的規定」\ (http://trustee.ietf.org/license-info) の適用を受ける。これらの文書には、本書に関する権利および制約が記載されているため、注意深く確認してほしい。本書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記載のとおり Simplified BSD License の文言を含めなければならず、また Simplified BSD License に記載のとおり無保証で提供される。

Table of Contents

1. Introduction

本書は、SCIM の定義、概要、概念、フロー、シナリオ、ユースケースを提供する。また、ユースケースから導出された要求事項の一覧も提供する。

本書の目的は、SCIM スキーマ [RFC7643] および SCIM プロトコル [RFC7644] の設計と適用可能性の理解を助けることである。

Federated Access Beyond web のための Application Bridging（ABFAB）や SAML2 WebSSO のような一部のプロトコルの慣行とは異なり、SCIM は認証（いわゆる just-in-time provisioning）とは別の文脈で、リソースのプロビジョニングおよびプロビジョニング解除を提供する。

1.1. Terminology

本書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、すべて大文字（ALL CAPS）で現れる場合、[RFC2119] に記載のとおり解釈される。これらの語は、規範的な意味を伴わない通常の英語として小文字で現れることもある。

本書で使用する頭字語および略語の一覧を以下に示す。

  • COI: Community of Interest
  • CRM: Customer Relationship Management
  • CRUD: Create, Read, Update, Delete
  • CSP: Cloud Service Provider
  • CSU: Cloud Service User
  • ECS: Enterprise Cloud Subscriber
  • IaaS: Infrastructure as a Service
  • JIT: Just In Time
  • PaaS: Platform as a Service
  • SaaS: Software as a Service
  • SAML: Security Assertion Markup Language
  • SCIM: System for Cross-domain Identity Management
  • SSO: Single Sign-On

2. SCIM User Scenarios

2.1. Background and Context

System for Cross-domain Identity Management（SCIM）仕様は、相互運用性、セキュリティ、スケーラビリティを実現するために、クラウドベースのアプリケーションおよびサービスにおけるユーザーのアイデンティティを標準化された方法で管理できるよう設計されている。この仕様群は、既存のスキーマおよび導入の経験を土台にしつつ、既存の認証、認可、プライバシーのモデルを適用しながら、開発と統合の容易さを特に重視している。SCIM 仕様の意図は、共通のユーザー・スキーマと拡張モデルを提供し、さらに標準プロトコルを用いてこのスキーマを交換するためのパターンを提供するためのバインディング文書を用意することで、ユーザー管理操作のコストと複雑さを低減することにある。要するに、クラウドへのユーザーの導入、クラウドからの削除、クラウド内での移動を、迅速に、安価に、容易に行えるようにする。

SCIM シナリオは、SCIM の取り組みの意図されたスコープを明確にするために設計されたユーザーストーリーの概要である。

2.2. Model Concepts

2.2.1. Triggers

端的に言えば、トリガーとは SCIM のフローを開始するアクションまたは活動である。トリガーはプロトコル・レベルやスキーマ・レベルでは関係しない場合があるが、SCIM プロトコルの交換が発生した原因となる種類や活動を特定する助けとなる。トリガーは、従来のプロビジョニング CRUD（Create, Read, Update, Delete）操作を利用するが、SSO（Single Sign-On）のような追加のユースケース文脈も加える。これは、プロトコル操作を説明するためというより、要求するアクターにとって意味のあるユースケースのクラスを捉えるために設計されている。

  • Create SCIM Identity Resource - Service On-boarding Trigger: 「create SCIM identity resource」トリガーは、新規採用や新規サービス購読などのビジネス上のアクションが、SCIM Actors のいずれかによって開始されるサービス導入（オンボーディング）活動である。プロトコル自体では、サービス導入は、サービス変更と同じリソース PUT メソッドで実装され得る。これは実装に固有の事項であり、その実装を駆動するユースケースに固有の事項ではない。
  • Update SCIM Identity Resource - Service Change Trigger: 「update SCIM identity resource」トリガーは、アイデンティティが移動する、またはサービス・レベルが変更されることの結果として生じるサービス変更活動である。「update SCIM identity」トリガーは、サービス購読レベルの変更、またはサービス購読レベルを示すために用いられる重要なアイデンティティ・データの変更の結果となり得る。パスワード変更は、より一般的なアイデンティティ属性の変更とは異なるユースケース上の違いがあると見なされるため、特に区別して扱われる。
  • Delete SCIM Identity Resource - Service Termination Trigger: 「delete SCIM identity resource」トリガーは、特定の SCIM サービス提供点からアイデンティティを削除するための、明確で意図的なアクションを表す。この段階では、SCIM プロトコルがサービス停止（suspension）アクションのために別個のプロトコル交換を識別する必要があるかどうかは不明である。ターゲット・サービスは通常これらの結果を区別するため、別個のリソース表現を必要とする可能性があり、これが関係する場合がある。
  • Single Sign-On (SSO) Trigger - Service Access Request: 「Single Sign-On」トリガーは、SSO の運用フロー中に Create または Update トリガーが開始される、特別なクラスの活動である。ここでの含意は、エンドユーザー（SSO）によるサービスアクセス要求の結果として、定義済みの SCIM プロトコル交換が、サービス・クラウド内のどこかで SCIM リソースの CRUD 操作を開始するために用いられ得る、ということである。

2.2.2. Actors

アクターとは、SCIM プロトコル交換の両側に参加する運用主体であり、特定の Trigger の発生源を特定する助けとなる。これまでに、以下の SCIM Actors を特定している。

  • Cloud Service Provider (CSP): CSP は、特定のクラウドサービスを運用する主体である。SaaS のシナリオでは、これは単にアプリケーション提供者である。IaaS または PaaS のシナリオでは、CSP は基盤となる IaaS/PaaS インフラストラクチャ提供者、またはそのプラットフォーム上で動作するアプリケーションの所有者である場合がある。いずれの場合も、CSP は操作対象となるアイデンティティ情報を保持している主体である。別の言い方をすれば、CSP はエンドユーザーが実際にやり取りするサービスそのものである。
  • Enterprise Cloud Subscriber (ECS): ECS は、関連するアイデンティティ記録を集約する中間層を表す。サンプルのエンタープライズ SaaS シナリオの一つでは、ECS は、営業スタッフ全員のためにクラウドベースの CRM サービス「SaaS-CRM Inc.」（CSP）を購読している「Example.com」である。実際の Cloud Service Users（CSUs）は FooBar Inc. の営業スタッフである。ECS Actor は、単一の主体が他のアイデンティティアカウントに対する管理責任を付与されるユースケースを捉える助けとして識別される。SCIM は CSP 内での ECS の設定やセットアップを扱わないかもしれないが、SCIM アイデンティティリソースがまとめてグループ化され、より広範な合意や運用上のやり取りの一部として管理されるユースケースは扱う。
  • Cloud Service User (CSU): CSU は、実際のクラウドサービスのエンドユーザー、すなわちクラウドサービスにログインして利用する人物を表す。上述のとおり、ECS は通常、複数の CSU アイデンティティを所有または管理するが、CSU は FooBar Inc. の従業員がクラウドサービスを用いて CRM の業務プロセスを管理することを表す。
                           +---------------------+
                           |   Cloud Service     |
                           |   Provider (CSP)    |
                           +---------------------+
                                      |
                    +--------------------------------+
                    |                                |
                    v                                v
            +----------------+              +----------------+
            |Enterprise Cloud|              |Enterprise Cloud|
            |Subscriber (ECS)|              |Subscriber (ECS)|
            +----------------+              +----------------+
                    |                                |
            +----------------+              +----------------+
            |                |              |                |
            v                v              v                v
    +-------------+ +-------------+   +-------------+ +-------------+
    |Cloud Service| |Cloud Service|   |Cloud Service| |Cloud Service|
    |  User (CSU) | |  User (CSU) |   |  User (CSU) | |  User (CSU) |
    +-------------+ +-------------+   +-------------+ +-------------+

                           Figure 1: SCIM Actors

2.2.3. Modes and Flows

モードは、SCIM シナリオにおいて開始されるデータフローの機能的な意図を示す。これまでに識別されたモードは 'Push' と 'Pull' であり、権威あるアイデンティティ・データ・ストアへデータを送ること、およびそこからデータを取得することを指す。

SCIM シナリオでは、モードはしばしば二者の Actors 間のフローという文脈で用いられる。例えば、クラウド間の Pull 交換を指すことがある。ここでは、ある Cloud Service Provider (CSP) が別の CSP からアイデンティティ情報を取得する。一般に参照されるフローは以下のとおりである。

  • Cloud Service Provider to Cloud Service Provider (CSP->CSP)
  • Enterprise Cloud Subscriber to Cloud Service Provider (ECS->CSP)

モードとフローは、何が起きているかを理解する助けとなるだけである。プロトコル・レベルでは技術的に意味を持たない可能性が高いが、読者が SCIM シナリオを追い、現実世界のユースケースに適用するのに役立つ。

2.2.4. Bulk and Batch Operational Semantics

本書で概説する各トリガーアクションは、より大きな一括（bulk）またはバッチ（batch）操作の一部となり得ると想定する。個々の SCIM アクションは、まとめて単一のプロトコル交換を作成できるべきである。

SCIM シナリオの初期の焦点は、基本フローと単一操作を識別することにある。本格的な一括およびバッチ操作の具体的な複雑さは、後続版のシナリオ、または本仕様に委ねる。

2.3. Flows from Cloud Service Provider to Cloud Service Provider

(CSP->CSP)

これらのシナリオは、2 つの Cloud Service Providers（CSPs）間のフローを表す。各 CSP は Cloud Service Users（CSUs）のための Identity Data Store を維持していると想定する。これらのシナリオは、joiner、mover、leaver、および JIT の各トリガーを扱い、CSP 間での push と pull のデータ交換の結果を示す。

2.3.1. CSP->CSP: Create Identity (Push)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。CSP-1 は、その Enterprise Cloud Subscriber（ECS-1）から Create Identity のトリガーアクションを受け取る。CSP-1 は新しい CSU のためにローカルのユーザーアカウントを作成する。その後、CSP-1 は新しい CSU の joiner push 要求を下流の CSU-2 に送信し、アカウントが正常に作成されたことの確認を得る。CSP-2 から確認を受け取った後、CSP-1 は要求元の ECS に確認応答を送る。

2.3.2. CSP->CSP: Update Identity (Push)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。Enterprise Cloud Subscriber（ECS-1）はすでに CSP-1 にアカウントを作成しており、CSP-1 がサービスオプションを決定するために用いる重要な属性「department」を提供している。その後、CSP-1 は Enterprise Cloud Subscriber（ECS）から Update Identity のトリガーアクションを受け取る。CSP-1 はローカルのディレクトリアカウントを新しい department の値で更新する。次に、CSP-1 は mover 変更要求を下流の CSP-2 へ送るために、別の SCIM プロトコル交換を開始する。CSP-2 から確認を受け取った後、CSP-1 は ECS-1 に確認応答を送る。

2.3.3. CSP->CSP: Delete Identity (Push)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。CSP-1 は Enterprise Cloud Subscriber（ECS-1）から Delete Identity のトリガーアクションを受け取る。CSP-1 は指定された CSU アカウントのローカルのディレクトリアカウントを停止（suspend）する。その後、CSP-1 は指定された CSU アカウントの終了（termination）要求を下流の CSP-2 へ送信し、アカウントが正常に削除されたことの確認を得る。CSP-2 から確認を受け取った後、CSP-1 は削除操作を完了し、要求元の ECS に確認応答を送る。

このユースケースは、同じ SCIM 操作の背後で、異なる CSP が異なる運用上の意味論を実装し得ることを示す。CSP-1 は自サービスにおけるアカウント表現を停止するのに対し、CPS-2 は実際の削除操作を実装している点に注意。

2.3.4. CSP->CSP: SSO Trigger (Push)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。しかし、CSP-1 から CSP-2 へ事前にアカウントをプロビジョニングするのではなく、CSP-1 は、エンドの Cloud Service User（CSU-1）からのサービスアクセス要求があるまで、CSP-2 に対してアカウント作成の詳細を発行しない。CSU が CSP-1 から CSP-2 への SSO トランザクションを完了すると、CSP-2 は CSP-1 から送られてきた情報に基づき CSU のアカウントを作成する。

プロトコル・レベルでは、このクラスのシナリオにより、CSP-1 と CSP-2 の間で共通のプロトコル交換パターンが用いられる可能性がある。

2.3.5. CSP->CSP: SSO Trigger (Pull)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。しかし、CSP-1 から CSP-2 へ事前にアカウントをプロビジョニングするのではなく、CSP-2 は Cloud Service User（CSU-1）からのサービスアクセス要求があるまで待ち、ローカルアカウントを作成するのに十分な CSU 情報を収集するための Pull 要求を開始する。

プロトコル・レベルでは、このクラスのシナリオにより、CSP-2 と CSP-1 の間で共通のプロトコル交換パターンが用いられる可能性がある。

2.3.6. CSP->CSP: Password Reset (Push)

このシナリオでは、2 つの CSP（CSP-1 と CSP-2）が、Cloud Service User（CSU）アカウントの交換を必要とする共有のサービス合意を結んでいる。CSP-1 は特定の Cloud Service User（CSU-1）のパスワードを変更したい。CSP-1 は CSU-1 のパスワード値をリセットする要求を CSP-2 に送信する。

プロトコル・レベルでは、このシナリオは他の属性変更要求と同じプロトコル交換になる可能性がある。

2.4. Flows from Enterprise Cloud Subscriber to Cloud Service Provider

(ECS->CSP)

これらのシナリオは、Enterprise Cloud Subscriber（ECS）と Cloud Service Providers（CSP）間のフローを表す。ECS と CSP はそれぞれ、関連する Cloud Service Users（CSUs）のための情報アクセスサービスを維持していると想定する。これらのシナリオは、joiner、mover、leaver、および JIT の各トリガーを扱い、ECS と CSP 間での push と pull のデータ交換の結果を示す。

これらのシナリオの多くは、Section 2.3 で定義されたものと非常によく似ている。ここでは、現れ得る差異を検討できるように、別途識別している。

2.4.1. ECS->CSP: Create Identity (Push)

このシナリオでは、Enterprise Cloud Subscriber（ECS-1）が、さまざまな Cloud Service User（CSU）アカウントの共有を必要とする Cloud Service Provider（CSP-1）とのサービスを維持している。新しいユーザーが ECS-1 に参加するため、ECS-1 はアカウント作成要求を CSP-1 に push し、基本 SCIM スキーマに必要なすべての属性値と、必要に応じて拡張 SCIM スキーマの追加値を提供する。

2.4.2. ECS->CSP: Update Identity (Push)

このシナリオでは、Enterprise Cloud Subscriber（ECS-1）が、Department というキーとなるアカウント・スキーマ属性からサービス定義を決定する Cloud Service Provider（CSP-1）とのサービスを維持している。ECS-1 は特定の CSU を Department A から Department B に移動させたいので、属性更新要求を CSP に push する。

2.4.3. ECS->CSP: Delete Identity (Push)

このシナリオでは、Enterprise Cloud Subscriber（ECS-1）が Cloud Service Provider（CSP-1）とのサービスを維持している。従業員の一人の雇用契約が終了した際、ECS-1 はアカウント停止（suspend）要求を CSP-1 に送る。1 週間後、ECS は Cloud Service User（CSU）アカウントを完全に削除する工程を完了したいので、アカウント終了（terminate）要求を CSP-1 に送る。

2.4.4. ECS->CSP: SSO Trigger (Pull)

このシナリオでは、Enterprise Cloud Subscriber（ECS-1）が Cloud Service Provider（CSP-1）とのサービスを維持している。アカウントは事前に作成も交換もされない。しかし、ECS-1 から CSP-1 へ事前にアカウントをプロビジョニングするのではなく、CSP-1 は、ECS-1 の管理ドメイン下にある Cloud Service User（CSU-1）からのサービスアクセス要求があるまで待ち、その後 ECS-1 に対してアカウントの Pull 要求を発行する。

3. SCIM Use Cases

本節では SCIM のユースケースを列挙する。

3.1. Migration of the Identities

Description:

企業 SomeEnterprise は、従業員に関するアイデンティティ情報（例: 識別子、属性）に依存するアプリケーション ManageThem を運用している。アイデンティティ情報は、SomeCSP が提供するクラウドに保存されている。SomeEnterprise は、アイデンティティ情報を別の提供者である AnotherCSP のクラウドへ移すことを決定した。さらに SomeEnterprise は、同じくアイデンティティ情報に依存する 2 つ目のアプリケーション ManageThemMore を購入した。SomeEnterprise は、アイデンティティ情報の形式を変更することなく AnotherCSP へ移すことができる。アプリケーション ManageThemMore はそのアイデンティティ情報を利用できる。

Pre-conditions:

  • SomeCSP は SomeEnterprise のクラウドサービス提供者である。
  • SomeCSP は、管理およびデータ転送に使用される Enterprise に対して、既知の属性名および値を持つ。
  • AnotherCSP は SomeEnterprise の新しいクラウドサービス提供者である。
  • 関与するすべてのクラウドサービス提供者とアプリケーションは、ユーザー（例: 従業員）のアイデンティティ情報の形式およびその情報に対する操作を規定する同一の標準をサポートする。

Post-conditions:

  • SomeEnterprise は、アイデンティティ情報の表現を変更することなく、従業員のアイデンティティ情報を SomeCSP から AnotherCSP へ移している。
  • アプリケーション ManageThemMore はそのアイデンティティ情報を利用できる。

Requirements:

  • SomeEnterprise、アプリケーション ManageThem と ManageThemMore、および提供者 SomeCSP と AnotherCSP は、アイデンティティ情報に関する共通標準をサポートし、その標準は以下を規定する。
    • 形式（またはスキーマ）：ユーザーのアイデンティティ情報を表現するための形式（またはスキーマ）
    • インタフェースとプロトコル：ユーザーのアイデンティティ情報を管理するためのインタフェースおよびプロトコル
  • クラウド提供者は、管轄地域（例: 国や州はプライバシーに関する規制が異なる可能性がある）をまたいでアイデンティティ情報を移行する際に、規制要件を満たせなければならない。
  • クラウド提供者は、SomeEnterprise の従業員のアイデンティティに関するすべてのアクションを記録できなければならない。
  • ログは安全であり、監査に利用可能であるべきである。

3.2. Single Sign-On (SSO) Service

Description:

Bob は、クラウドサービス提供者 SomeCSP にホストされたアプリケーションのアカウントを持つ。SomeCSP は、クラウドサービス提供者 AnotherCSP とユーザーのアイデンティティをフェデレーションしている。Bob は AnotherCSP 上で動作するアプリケーションからサービスを要求する。AnotherCSP 上で動作するアプリケーションは、SomeCSP による Bob の認証に依存し、SomeCSP が提供するアイデンティティ情報を用いて、Bob の要求に応える。

Pre-conditions:

  • Bob のアイデンティティ情報は SomeCSP に保存されている。
  • SomeCSP と AnotherCSP は信頼関係を確立し、ユーザーのアイデンティティをフェデレーションしている。
  • SomeCSP は Bob を認証できる。
  • SomeCSP は認証結果を AnotherCSP に安全に提供できる。
  • SomeCSP は Bob のアイデンティティ情報（例: 属性）を AnotherCSP に安全に提供できる。
  • AnotherCSP は SomeCSP が提供する情報を検証できる。
  • SomeCSP は AnotherCSP から受け取ったアイデンティティ情報を処理できる。

Post-conditions:

Bob は、AnotherCSP 上で動作するアプリケーションに対して明示的に認証することなく、要求したサービスを受け取る。

Requirements:

  • Bob は SomeCSP にアカウントを持たなければならない。
  • SomeCSP と AnotherCSP は信頼関係を確立し、ユーザーのアイデンティティをフェデレーションしなければならない。
  • SomeCSP は Bob を認証できなければならない。
  • SomeCSP は認証結果を AnotherCSP に安全に提供できなければならない。
  • SomeCSP は Bob のアイデンティティ情報（例: 属性）を AnotherCSP に安全に提供できなければならない。
  • AnotherCSP は SomeCSP が提供するアイデンティティ情報を検証できなければならない。
  • SomeCSP は AnotherCSP から受け取ったアイデンティティ情報を処理できなければならない。
  • SomeCSP と AnotherCSP は、両者のポリシーおよび両者間の信頼合意に従って、Bob の行為により生成される情報を記録しなければならない。

3.3. Provisioning of the User Accounts for a Community of Interest

(COI)

Description:

組織 YourHR は、Community of Interest（COI）である YourCOI に対して Human Resources（HR）サービスを提供する。HR サービスは、パブリックおよびプライベートクラウド上で Software as a Service（SaaS）として提供される。YourCOI のオフィスは世界中に所在する。同組織の Information Technology（IT）システムは、プライベートクラウドとパブリッククラウド上で動作するアプリケーションの組み合わせと、従来型の IT システムの組み合わせで構成される可能性がある。各地域の YourCOI オフィスは、個人情報（すなわちユーザーのアイデンティティと属性）の収集に責任を負う。YourHR のサービスは、従業員のアイデンティティ情報を YourCOI の全オフィスへプロビジョニングし配布するための手段を提供する。また YourHR は、個々のユーザー（例: 従業員）が自分の責任範囲にある個人情報（例: 住所や電話番号の更新）を管理できるようにする。

Pre-conditions:

  • YourCOI は、多数の地域オフィスからなる複雑なインフラストラクチャを持ち、各オフィスは多様な IT システムに依存している。
  • YourCOI は HR サービスを提供するために YourHR と契約している。
  • 各地域オフィスは、従業員の個人アカウントを作成する権利を持つ。

Post-conditions:

  • すべての個人アカウントは、YourHR が提供するサービスを通じて、YourCOI システム全体にわたり、権限を与えられた任意のユーザーまたはアプリケーションがグローバルに利用可能となる。
  • 従業員は、自分が責任を負う範囲の個人情報を管理できる。

Requirements:

  • YourHR は、地域オフィスが生成する情報が安全にプロビジョニングされ、技術（例: プロトコルおよびアプリケーション）、管理（例: 企業）、規制（例: 所在地）、および法域（jurisdictional）ドメインにまたがり得るシステム全体に対して、プライバシー要件を適時に考慮しながら展開されることを保証しなければならない。
  • 個人情報の管理は、不正アクセスおよび盗聴から保護されなければならず、権限を与えられた主体およびサービスにのみ配布されるべきである。
  • 管轄地域（例: 国や州はプライバシーに関する規制が異なる可能性がある）をまたいでアイデンティティ情報を移行する際には、規制要件を満たさなければならない。
  • アイデンティティ・データに関するすべての操作は、安全に記録されなければならない。
  • ログは監査に利用可能であるべきである。

3.4. Transfer of Attributes to a Relying Party's Website

Description:

エンドユーザーは、1 つ以上の属性を持つディレクトリサービス A のアカウントを持つ。そのユーザーが relying party B のウェブサイトを訪れ、そのウェブサイトがユーザーの属性を要求する。ユーザーは一部の属性を選択し、認可プロトコル（例: OAuth, SAML）を介したデータ転送を許可することで、選択されたユーザー属性が、当該サイトへのユーザーの初回訪問時に、ディレクトリサービス A のユーザーアカウントから replying party B のウェブサイトへ転送される。

Pre-conditions:

  • User はディレクトリサービス A にアカウントを持つ。
  • User は 1 つ以上の属性を持つ。
  • User は relying party B のウェブサイトを訪れる。

Post-conditions:

選択されたユーザー属性が、当該サイトへのユーザーの初回訪問時に、ディレクトリサービス A のユーザーアカウントから relying party B のウェブサイトへ転送される。

Requirements:

  • relying party B はエンドユーザーを認証できなければならない。
  • relying party B は認証結果をディレクトリサービス A に安全に提供できなければならない。
  • ディレクトリサービス A はエンドユーザーのアイデンティティ情報（例: 属性）を relying party B に安全に提供できなければならない。
  • 管轄地域（例: 国や州はプライバシーに関する規制が異なる可能性がある）をまたいでアイデンティティ情報を移行する際には、規制要件を満たさなければならない。
  • relying parties は、キャッシュしている複製の変更を把握する必要がある。これらの変更は、他の relying parties における状態変更を引き起こす可能性があるためである。
  • relying party が情報をキャッシュする最大期間を設定すべきである。

3.5. Change Notification

Description:

エンドユーザーは、1 つ以上の属性を持つディレクトリサービス A のアカウントを持つ。そのユーザーが relying party B のウェブサイトを訪れる。relying party B のウェブサイトは、そのユーザーに関連する属性および関連リソースについて、ディレクトリサービス A に問い合わせる。

その後、ディレクトリサービス A におけるユーザーの属性が変更される。例えば、ユーザーが氏名を変更したり、アカウントが無効化されたり、ディレクトリサービス A との関係を終了した場合に属性が変更され得る。さらに、他のリソースおよびそれらの属性も変更され得る。ディレクトリサービス A はこれらの変更を relying party B のウェブサイトに通知したい。relying party B は（持っている場合も持っていない場合もあるが）それらの属性をキャッシュしている可能性があり、relying party B がキャッシュ複製に対する変更を把握すると、relying party B における状態変更を引き起こす可能性があるためである。

しかし、変更の量は相当なものになり得るうえ、変更のうち relying party B にとって関心があるのは一部だけかもしれないため、ディレクトリサービス A はすべての変更を B に「push」したいわけではない。代わりに、ディレクトリサービス A は、関心があり得る変更が存在することを B に通知したい。そうすることで、B は適切なタイミングで後続的にディレクトリサービス A に連絡し、B が関心を持つ変更の部分集合だけを取得できる。

なお、ユーザーはディレクトリサービス A がウェブサイトへデータを転送することを許可しなければならず、またディレクトリサービス A がウェブサイトへ通知することも許可しなければならない。

Pre-conditions:

  • User はディレクトリサービス A にアカウントを持つ。
  • User は 1 つ以上の属性を持つ。
  • User は relying party B のウェブサイトを訪れる。
  • 更新対象のリソースはウェブサイト上にある。

Post-conditions:

ディレクトリサービス A は、関心があり得る変更が存在することを relying party B に通知できる。

Requirements:

  • relying party B はエンドユーザーを認証できなければならない。
  • relying party B は認証結果をディレクトリサービス A に安全に提供できなければならない。
  • ディレクトリサービス A は、変更されたエンドユーザーのアイデンティティ情報（例: 属性）を relying party B に安全に提供できなければならない。
  • relying party B は適切なタイミングで後続的にディレクトリサービス A に連絡し、B が関心を持つ変更の部分集合だけを取得できなければならない。

4. Security Considerations

SCIM の操作に対しては、認証済みの主体のみが SCIM 要求を実行でき、要求された SCIM 操作が認可されていることを保証するために、認証および認可が確実に行われなければならない。

SCIM リソース（例: Users や Groups）には機微な情報が含まれ得る。したがって、輸送層においてデータの機密性が保証されなければならない。

さらに、輸送層のセキュリティを超えたプライバシー問題が生じ得る。例えば、個人を特定し得る情報（PII）を CSP 間で国外に移動させる場合がある。管轄地域（例: 国や州はプライバシーに関する規制が異なる可能性がある）をまたいでアイデンティティ情報を移行する際には、規制要件を満たさなければならない。

また、プライバシーに配慮したデータ要素は、ユーザーのためにこれらのデータ要素を保護する目的で、SCIM トランザクションまたは保存記録において省略されたり秘匿されたりする場合がある。例えば、個人名の代わりに役割に基づく識別子を使用することがある。

詳細なセキュリティ上の考慮事項は、SCIM プロトコル [RFC7644] の Section 7 および SCIM スキーマ [RFC7643] の Section 9 に規定されている。

5. References

5.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.

5.2. Informative References

[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.

[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,\ and C. Mortimore, "System for Cross-domain Identity\ Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,\ September 2015, http://www.rfc-editor.org/info/rfc7644.

Acknowledgments

著者らは、Ray Counterman、Richard Fiekowsky、Bert Greevenbosch、Barry Leiba、Kelly Grizzle、Magnus Nystrom、Stephen Farrell、Kathleen Moriarty、Benoit Claise、Dapeng Liu、Jun Li のレビューとコメントに感謝する。

また、Darran Rolls と Patrick Harding にも感謝する。Section 2（「SCIM User Scenarios」）は彼らの成果から採られている。

Authors' Addresses

Kepeng LI (editor)\ Alibaba Group\ 969 Wenyixi Road, Yuhang District\ Hangzhou, Zhejiang 311121\ China

Email: kepeng.lkp@alibaba-inc.com

Phil Hunt\ Oracle

Email: phil.hunt@oracle.com

Bhumip Khasnabish\ ZTE (TX) Inc.\ 55 Madison Ave, Suite 302\ Morristown, New Jersey 07960\ United States

Phone: +001-781-752-8003\ Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com\ URI: http://tinyurl.com/bhumip/

Anthony Nadalin\ Microsoft

Email: tonynad@microsoft.com

Zachary Zeltsan\ Individual

Email: Zachary.Zeltsan@gmail.com