docname: draft-ipsie-scim-al1-profile-latest submissiontype: "independent" number: date: v: 1 workgroup: IPSIE Working Group keyword:

scim
ipsie venue: group: IPSIE type: Working Group mail: openid-specs-ipsie@lists.openid.net arch: https://openid.net/wg/ipsie/ github: "openid/ipsie-scim-al1" latest: "https://openid.github.io/ipsie-scim-al1/draft-ipsie-scim-al1-profile.html"

author:

fullname: Mark Maguire
organization: Aujas Cybersecurity
email: mark.maguire@aujas.com

fullname: Jen Schreiber organization: SGNL email: jen@sgnl.ai

normative: RFC8174: RFC2119: RFC7523: RFC7643: RFC7644: RFC6749: RFC8414:

--- abstract

本書は、企業内のアイデンティティ・ライフサイクル管理におけるセキュリティ要件および相互運用性要件を満たすための、SCIM 2.0のプロファイルを定義する。SCIMの文脈において、このプロファイルは、プロビジョニング、アカウント管理、クライアント認証、ならびにアイデンティティ同期に関する要件を定める。

--- middle

Introduction

本書は、SCIM 2.0向けのIPSIE Account Lifecycle 1 (AL1) Profileを定義する。相互運用可能な企業アイデンティティ管理のベストプラクティスに合致した、明確に定義されたセキュリティ・ベースラインを必要とするSCIM導入に対し、明確な参照を提供する。

このプロファイルは、安全なアイデンティティ管理の重要な側面を扱い、とりわけ次の点を重視する。

クライアント認証
Users の取得、追加、変更
Groups の取得、追加、変更
Identity Service から Application へのデータ同期

このプロファイルに従うことで、組織は、厳格なセキュリティ要件を満たしつつ、異なる実装間での相互運用性を確保するSCIMベースの連携を実装できる。

Conventions and Definitions

本書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、ここに示すようにすべて大文字で表記される場合に限り、BCP 14 [RFC2119] [RFC8174] に記載のとおり解釈される。

Terminology

SCIM

{{RFC7643}} および {{RFC7644}} で定義される System for Cross-domain Identity Management

SCIM Client

サービス提供者によって管理されるアイデンティティ・データを、SCIMプロトコルを用いて管理するアプリケーション。クライアントは、対象のサービス提供者に対してSCIMのHTTPリクエストを開始する。

SCIM Service Provider

SCIMプロトコルを介してアイデンティティ情報を提供するHTTP Webアプリケーション。

Role

TODO: 定義を追加

Identity Service

SCIM Client として動作し、すべてのプロビジョニング操作を開始する。

Application

SCIM Service Provider として動作し、SCIMエンドポイントをホストし、すべてのプロビジョニング要求を処理する。

注: SCIMをIPISIEの文脈に適用する場合、Identity Service は SCIM Client として動作し、Application は SCIM Service Provider として動作する。本書では、IPSIE Profiles 間の一貫性を保つため、以下の Role の用語を使用する。

Profile

Authentication and Authorization

Identity Service と Application は、SCIMプロトコルにおける認証および認可のために、OAuth 2.0 {{RFC6749}} を使用しなければならない。

// TODO: これはSL1へのリンクに戻すべきか？

// TODO: セクションを拡張

以下の要件は、Access Token と Authorization Server 構成を一貫して安全に取り扱うことを保証する。

// TODO: トークン名をより明確にする。

OAuth 2.0 の相互作用は、{{RFC7523}} で定義される JWT Client Authentication に準拠しなければならない。
トークンは、署名付きJWTをAccess Tokenと交換し、そのトークンを以後のすべてのSCIMリクエストにおいて {Authorization: Bearer} ヘッダで提示しなければならない。
トークンには "token_endpoint" の値を含めなければならない。これは、Identity Service の OAuth 2.0 token endpoint のURLである。
Acess Token には "scim" scope を含めなければならず、より広い権限を付与してはならない。
すべての Authorization Server パラメータは、{{RFC8414}} で定義される OAuth Authorization Server メタデータからディスカバリされることが望ましい。
Identity Service は、Application が署名検証を行えるように、jwks_uri を公開することが望ましい。

SCIM Interoperability Requirements

General Requirements

Identity Service は、{{RFC7643}} および {{RFC7644}} で定義される SCIM Client の必須機能を実装しなければならない。
Application は、{{RFC7643}} および {{RFC7644}} で定義される SCIM Service Provider の必須機能を実装しなければならない。
すべてのSCIM操作は、{{authn-authz}} に記載のとおり、OAuth 2.0 により認証および認可されなければならない。
Application における Users または Groups のローカル変更は禁止される。

User Provisioning Operations

Application は、本節で定義されるすべての User プロビジョニング操作をサポートしなければならない。

Create User (POST /Users)

User の作成は、SCIM操作 POST /Users により行う。

{{RFC7643}} で必須とされる User 属性に加えて、以下の属性が User スキーマの一部として必須である。

// TODO: これを曖昧に保つか、要求する属性を明示すべきか？ email vs emails?

"externalId" のように、企業がアカウントの所有者を識別するために用いる一意識別子を含む属性。
"email" のように、ユーザーの主要メールアドレスを含む属性。

Update User (PATCH /Users/{id})

User の更新は、SCIM操作 PATCH /Users/{id} により行う。

Deactivate or Reactivate User (PATCH /Users/{id})

無効化および再有効化などのユーザー有効化状態の変更は、SCIM操作 PATCH /Users/{id} により行う。

Identity Service は、ユーザーが無効化されてから5分以内に、ユーザー無効化イベントをApplicationへ伝播することが望ましい。

Application は、ユーザー無効化イベントに対して、現在アクティブなセッションの無効化を含め、ユーザーがApplicationへ継続してアクセスする能力を取り消すことで応答することが望ましい。無効化の仕組みは本プロファイルのスコープ外である。無効化は、無効化要求を受信してから5分以内に行われることが望ましい。

ユーザーアカウントが無効化された場合、そのアカウントに関連付けられたすべてのアクセス手段および認可も無効化されなければならない。これには、次のものが含まれるが、これらに限られない。

Webセッション
APIトークン
Refresh Token
個人用アクセストークン
ユーザーに関連付けられたSSH鍵
デバイスベースの認証資格情報

Application は、無効化されたユーザーの再有効化を許可しなければならない。

Delete User (DELETE /Users/{id})

User の削除は、SCIM操作 DELETE /Users/{id} により行う。

ユーザーが削除された後、Application は同じ username を持つ新しいユーザーの作成を許可しなければならない。

// TODO: これはユーザーのデータ維持の観点で難しい可能性がある

Get All Users (GET /Users)

システム内のすべてのユーザーの取得は、SCIM操作 GET /Users により行う。

このエンドポイントは、すべてのユーザーがIdentity Serviceによって管理されることを保証する。

Applicationから大量のデータを読み取れるようにするため、application は、GET /Users リクエストに対して、インデックスベースまたはカーソルベースのページネーションをサポートしなければならない。システムの安定性を確保し濫用を防ぐため、Application はこのエンドポイントにレート制限を適用しなければならず、制限を超えた場合には "429 Too Many Requests" や "Retry-After" などの適切なヘッダを付して応答しなければならない。

Get User By ID (GET /Users/{id})

id による User の検索は、SCIM操作 GET /Users/{id} により行う。

List Users By Alternate Identifier (GET /Users?)

別の識別子による User の検索は、SCIM操作 GET /Users?filter={filterExpression} により行う。

Application Providers は、次の filter expression をサポートしなければならない。

username eq {username}
externalId eq {externalId}
emails[value eq {email}]

Group (Role) Provisioning Operations

Application は、本節で定義されるすべての Group のプロビジョニング操作をサポートしなければならない。

注: IPSIE標準では、Application の権限は "Roles" と呼ばれる。SCIMでは、Application の権限は "Groups" と呼ばれる。IPSIEにおける "Role" は、SCIMにおける "Group" と機能的に同等である。

Create Group (POST /Groups)

Group の作成は、SCIM操作 POST /Group により行う。

// TODO: 詳細を追加

Get All Groups (GET /Groups)

システム内のすべてのグループの検索は、SCIM操作 GET /Groups により行う。

このエンドポイントは、すべてのグループがIdentity Serviceによって管理されることを保証する。

Applicationから大量のデータを読み取れるようにするため、application は、GET /Groups リクエストに対して、インデックスベースまたはカーソルベースのページネーションをサポートしなければならない。システムの安定性を確保し濫用を防ぐため、Application はこのエンドポイントにレート制限を適用しなければならず、制限を超えた場合には "429 Too Many Requests" や "Retry-After" などの適切なヘッダを付して応答しなければならない。

Get Group By ID (GET /Group/{id})

id による Group の検索は、SCIM操作 GET /Group/{id}?excludedAttributes=members により行う。

List Groups By Alternate Identifier (GET /Groups?)

別の識別子による User の参照は、SCIM操作 GET /Groups?filter={filterExpression}&excludedAttributes=members により行う。

Application Providers は、次の filter expression をサポートしなければならない。

// TODO: サポート必須のフィルタを追加

Add or Remove Group Members (PATCH /Group/{id})

Members の追加または削除は、SCIM操作 PATCH /Groups/{id} により Groups に対して行う。

PATCH 内の各 Operation について:

op 属性には "add" または "remove" のいずれかを含めなければならない。

op が "add" の場合:
- path 属性は "members" でなければならない。
- value 属性は、SCIM Core Schema {{RFC7643}} の Section 4.2 で定義される Group member 要素の配列でなければならない。各 member は、グループへ追加されるリソースの id を示す value サブ属性を含めなければならない。

op が "remove" の場合:
- path 属性は次のいずれかでなければならない。
  - "members"（すべてのメンバーを削除する）
  - "members[value eq {id}]"（単一のメンバーを削除する）
- value 属性は指定してはならない。

Metadata Endpoints

ResourceTypes

Application は、{{RFC7644}} の Section 4 で定義される /ResourceTypes エンドポイントをホストしなければならない。

サポートされる ResourceTypes には Users と Groups を含めなければならない。

ServiceProviderConfig

Application Providers は、{{RFC7644}} の Section 4 で定義されるとおり、サポートする操作を記述するために /ServiceProviderConfig エンドポイントをホストしなければならない。

操作には、少なくとも、このIPSIEプロファイルとの互換性に必要なSCIM機能のセットを含めなければならない。

Schemas

Application Providers は、{{RFC7644}} の Section 4 で定義されるとおり、サポートするスキーマを記述するために /Schemas エンドポイントをホストしなければならない。Users と Groups の両方に対するスキーマが存在しなければならない。スキーマには、RFC 7643 および Section 3.2.3 (Create User) における必須属性をすべて含めなければならない。

Security Considerations

SCIMのセキュリティ上の考慮事項については、{{RFC7643}} および {{RFC7644}} を参照のこと。

さらに、セキュリティ上の考慮事項に対処するため、以下の要件を含める。

Transport Security: すべてのエンドポイントは、強力な暗号スイートおよび証明書検証を伴う TLS 1.2 以降を強制しなければならない。
Error Handling: エラー応答はSCIMのエラー形式を使用しなければならず、内部の詳細を漏えいしてはならない。
Replay Resistance: Access Token は失効期限を持たなければならず、nonce はリプレイを防ぐために検証されなければならない。
Auditing: すべてのプロビジョニング操作および応答は、監査およびトラブルシューティングのためにログへ記録されなければならない。
Rate Limiting: すべてのエンドポイントはレート制限を強制しなければならず、制限を超えた場合は "429 Too Many Requests" で応答しなければならない。

Compliance Statement

本プロファイルにおけるすべての必須要件を実装すると、IPSIE Identity Lifecycle Level 1 (IL1) を満たす SCIM 2.0 デプロイメントとなる。具体的には次のとおり。

Identity Service (SCIM client)
- Users および Groups に対するすべてのCRUD操作を開始しなければならない。
- 上記のセキュリティ上の考慮事項に従わなければならない。

Application (SCIM service provider)
- User および Group のプロビジョニングを完全にサポートし、すべてのSCIMエンドポイントをホストしなければならない。
- SCIMの外で行われるローカル変更を防止しなければならない。
- 認証のために OAuth 2.0 JWT Profile {{RFC7523}} を強制しなければならない。
- 上記のセキュリティ上の考慮事項に従わなければならない。

このプロファイルに適合することで、実装は、企業のアイデンティティ・ライフサイクル管理に向けた、一貫性があり、安全で、相互運用可能なベースラインを達成する。