Skip to content

title: "IPSIE AL1 SCIM 2.0 Profile" abbrev: "IPSIE AL1 SCIM" category: info

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

本書は、enterprise における identity lifecycle management のセキュリティおよび相互運用性要件を満たすための、SCIM 2.0 のプロファイルを定義します。SCIM の文脈において、本プロファイルは provisioning、account management、client authentication、および identity synchronization に関する要件を定めます。

--- middle

Introduction

本書は、SCIM 2.0 向けの IPSIE Account Lifecycle 1（AL1）Profile を定義します。これは、相互運用可能な enterprise identity management に関するベストプラクティスを満たす、明確に定義されたセキュリティベースラインを必要とする SCIM 導入のための、明確な参照を提供します。

本プロファイルは、安全な identity management の重要な側面を扱い、特に以下に重点を置きます。

  • Client authentication
  • 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}} で定義される The System for Cross-domain Identity Management

SCIM Client

service provider によって保持される identity data を管理するために SCIM protocol を使用する Application。client は、対象となる service provider に対して SCIM の HTTP requests を開始します。

SCIM Service Provider

SCIM protocol を介して identity information を提供する HTTP Web application。

Role

TODO: 定義を追加

Identity Service

SCIM client として動作し、すべての provisioning operations を開始します。

Application

SCIM service provider として動作し、SCIM endpoints をホストして、すべての provisioning requests を処理します。

Note: SCIM を IPISIE の文脈に適用する場合、Identity Service は SCIM client として動作し、Application は SCIM service provider として動作します。本書では、IPSIE Profiles 間での一貫性のため、以下の Role 用語を用います。

Profile

Authentication and Authorization

Identity Service と Application は、SCIM protocol の認証および認可のために OAuth 2.0 {{RFC6749}} を使用しなければなりません（MUST）。

// TODO: Should this link back to SL1?

// TODO: Expand Section

以下の要件は、Access Token と Authorization Server の設定を、一貫性があり安全に取り扱うことを保証します。

// TODO: Be more explicit with token names.

  • OAuth 2.0 の相互作用は、{{RFC7523}} で定義される JWT Client Authentication に準拠しなければなりません（MUST）。
  • token は、署名済み JWT を access token に交換し、その token を以後のすべての SCIM requests において {Authorization: Bearer} header で提示しなければなりません（SHALL）。
  • token には "token_endpoint" 値を含めなければなりません（MUST）。この値は Identity Service の OAuth 2.0 token endpoint の URL です。
  • Acess Token には "scim" scope を含めなければならず（MUST）、それ以上に広い権限を付与してはなりません（MUST NOT）。
  • すべての Authorization Server parameters は、{{RFC8414}} で定義される OAuth Authorization Server metadata から発見することが望ましいです（SHOULD）。
  • Identity Service は、Application が署名検証を行えるように jwks_uri を公開することが望ましいです（SHOULD）。

SCIM Interoperability Requirements

General Requirements

  • Identity Service は、{{RFC7643}} および {{RFC7644}} で定義される SCIM client の必須機能を実装しなければなりません（SHALL）。
  • Application は、{{RFC7643}} および {{RFC7644}} で定義される SCIM service provider の必須機能を実装しなければなりません（SHALL）。
  • すべての SCIM operations は、{{authn-authz}} で規定されるとおり OAuth 2.0 を介して認証および認可されなければなりません（SHALL）。
  • Application における Users または Groups のローカル変更は禁止されます。

User Provisioning Operations

Application は、本節で定義されるすべての User provisioning operations をサポートしなければなりません（MUST）。

Create User (POST /Users)

User 作成は、SCIM operation の POST /Users により行われます。

{{RFC7643}} で要求される user attributes に加えて、以下の attributes は User schema の一部として要求されます。

// TODO: Should we keep this vauge or refer be explicit with attributes we are requiring? email vs emails?

  • enterprise が account の所有者を識別するために用いる一意の識別子を含む attribute（例："externalId."）
  • ユーザーの primary email address を含む attribute（例："email"）

Update User (PATCH /Users/{id})

User の更新は、SCIM operation の PATCH /Users/{id} により行われます。

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

deactivation および reactivation など、ユーザーの activation status の変更は、SCIM operation の PATCH /Users/{id} により行われます。

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

Application は、ユーザーが Application へのアクセスを継続できないようにするため、ユーザーの無効化イベントに応答することが望ましいです（SHOULD）。これには、現在アクティブな sessions の失効も含まれます。失効の仕組みは本プロファイルのスコープ外です。失効は、無効化リクエストを受信してから 5 分以内に行われることが望ましいです（SHOULD）。

ユーザー account が無効化された場合、その account に関連付くすべての access mechanisms と authorizations も無効化されなければなりません（MUST）。これには、以下を含みます（ただしこれらに限りません）。

  • Web sessions
  • API tokens
  • Refresh tokens
  • Personal access tokens
  • ユーザーに関連付く SSH keys
  • device-based authentication credentials

Application は、無効化されたユーザーの reactivation を許可しなければなりません（MUST）。

Delete User (DELETE /Users/{id})

User の削除は、SCIM operation の DELETE /Users/{id} により行われます。

ユーザーが削除された後、Application は同じ username を持つ新しい user の作成を許可しなければなりません（MUST）。

// TODO: this could be tricky RE: maintianing the user's data

Get All Users (GET /Users)

システム内のすべての users の取得は、SCIM operation の GET /Users により行われます。

この endpoint は、すべての users が Identity Service により管理されることを保証します。

Application から大量のデータを読み取れるようにするため、application は GET /Users リクエストに対して index-based または cursor-based pagination をサポートしなければなりません（must）。また、システムの安定性を確保し、濫用を防ぐため、Application はこの endpoint に rate limits を適用しなければなりません（SHALL）。制限を超過した場合は、「429 Too Many Requests」や「Retry-After」などの適切な headers を付けて応答しなければなりません（must）。

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

id による User 検索は、SCIM operation の GET /Users/{id} により行われます。

List Users By Alternate Identifier (GET /Users?)

alternate identifier による User 検索は、SCIM operation の GET /Users?filter={filterExpression} により行われます。

Application Providers は、以下の filter expressions をサポートしなければなりません（MUST）。

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

Group (Role) Provisioning Operations

Application は、本節で定義されるすべての Group provisioning operations をサポートしなければなりません（MUST）。

Note: IPSIE standard では Application permissions を「Roles」と呼びます。SCIM では Application permissions を「Groups」と呼びます。IPSIE における「Role」は、SCIM における「Group」と機能的に同等です。

Create Group (POST /Groups)

Group の作成は、SCIM operation の POST /Group により行われます。

// TODO: Add more details

Get All Groups (GET /Groups)

システム内のすべての groups の検索は、SCIM operation の GET /Groups により行われます。

この endpoint は、すべての groups が Identity Service により管理されることを保証します。

Application から大量のデータを読み取れるようにするため、application は GET /Groups リクエストに対して index-based または cursor-based pagination をサポートしなければなりません（MUST）。また、システムの安定性を確保し、濫用を防ぐため、Application はこの endpoint に rate limits を適用しなければなりません（SHALL）。制限を超過した場合は、「429 Too Many Requests」や「Retry-After」などの適切な headers を付けて応答しなければなりません（MUST）。

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

id による Group 検索は、SCIM operation の GET /Group/{id}?excludedAttributes=members により行われます。

List Groups By Alternate Identifier (GET /Groups?)

alternate identifier による User の参照は、SCIM operation の GET /Groups?filter={filterExpression}&excludedAttributes=members により行われます。

Application Providers は、以下の filter expressions をサポートしなければなりません（MUST）。

// TODO: Add what filters are required to be supported

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

members は、SCIM operation の PATCH /Groups/{id} により Groups に追加または削除されます。

PATCH 内の各 Operation について：

op attribute は "add" または "remove" のいずれかを含まなければなりません（MUST）。

  • op が "add" の場合：
  • path attribute は "members" でなければなりません（MUST）。

  • value attribute は、SCIM Core Schema の Section 4.2（{{RFC7643}}）で定義される Group member elements の配列でなければなりません（MUST）。各 member は、group に追加される resource の id を value subattribute に含まなければなりません（MUST）。

  • op が "remove" の場合：

  • path attribute は次のいずれかでなければなりません（MUST）。
    • "members"（すべての members を削除する）
    • "members[value eq {id}]"（単一の member を削除する）
  • value attribute は指定してはなりません（MUST）。

Metadata Endpoints

ResourceTypes

Application は、{{RFC7644}} の Section 4 で定義される /ResourceTypes endpoint をホストしなければなりません（MUST）。

サポートされる ResourceTypes には Users と Groups を含めなければなりません（MUST）。

ServiceProviderConfig

Application Providers は、{{RFC7644}} の Section 4 で定義されるとおり、サポートする operations を記述するために /ServiceProviderConfig endpoint をホストしなければなりません（MUST）。

operations には、少なくとも本 IPSIE プロファイルとの互換性に必要な SCIM capabilities の集合を含めなければなりません（MUST）。

Schemas

Application Providers は、{{RFC7644}} の Section 4 で定義されるとおり、サポートされる schemas を記述するために /Schemas endpoint をホストしなければなりません（MUST）。Users と Groups の両方に対する schema が存在しなければなりません。schemas には RFC 7643 の必須 attributes と、Section 3.2.3（Create User）の必須 attributes のすべてを含めなければなりません（must）。

Security Considerations

SCIM の Security Considerations については {{RFC7643}} と {{RFC7644}} を参照してください。

加えて、Security Considerations に対処するため、以下の requierements を含めます。

  • Transport Security: すべての endpoints は、強力な cipher suites と証明書検証を伴う TLS 1.2 以降を強制しなければなりません（SHALL）。
  • Error Handling: error responses は SCIM の error format を使用しなければならず（SHALL）、内部詳細を漏えいしてはなりません（SHALL NOT）。
  • Replay Resistance: replay を防ぐため、Access Token は失効しなければならず（SHALL）、nonce は検証されなければなりません（SHALL）。
  • Auditing: すべての provisioning actions と responses は、監査およびトラブルシューティングのためにログ記録されなければなりません（SHALL）。
  • Rate Limiting: すべての endpoints は rate limiting を強制しなければならず（SHALL）、制限超過時は「429 Too Many Requests」で応答しなければなりません（must）。

Compliance Statement

本プロファイルにおける必須要件のすべてを実装することで、IPSIE Identity Lifecycle Level 1（IL1）を満たす SCIM 2.0 の導入となります。具体的には次のとおりです。

  • Identity Service（SCIM client）
  • Users および Groups に対するすべての CRUD operations を開始しなければなりません（SHALL）。

  • 上記の Security Considerations に従わなければなりません（SHALL）。

  • Application（SCIM service provider）

  • User と Group の provisioning を完全にサポートする、すべての SCIM endpoints をホストしなければなりません（SHALL）。
  • SCIM 以外のローカル変更を防止しなければなりません（SHALL）。
  • Authentication のための OAuth 2.0 JWT Profile {{RFC7523}} を強制しなければなりません（SHALL）。
  • 上記の Security Considerations に従わなければなりません（SHALL）。

本プロファイルに適合することで、実装は、enterprise identity lifecycle management のための一貫した、安全で、相互運用可能なベースラインを達成します。