Skip to content

RFC 7644: System for Cross-domain Identity Management: Protocol (JA)

  • "P. Hunt (Ed.), Oracle"
  • "K. Grizzle, SailPoint"
  • "M. Ansari, Cisco"
  • "E. Wahlstroem, Nexus Technology"
  • "C. Mortimore, Salesforce" issn: "2070-1721"

Abstract

System for Cross-domain Identity Management（SCIM）仕様は、標準化されたサービスを通じて、複数ドメインにまたがるシナリオにおけるアイデンティティ管理を容易に支援する、HTTP ベースのプロトコルである。例としては、企業からクラウドのサービスプロバイダへの連携や、クラウド間のシナリオなどが挙げられるが、これらに限られない。本仕様群は、既存のスキーマや導入実績で得られた経験を基にしつつ、開発および統合の容易さに特に重点を置き、既存の認証・認可・プライバシーモデルを適用することを目指す。SCIM の狙いは、共通のユーザースキーマ、拡張モデル、本書で定義されるサービスプロトコルを提供することで、ユーザー管理操作のコストと複雑さを低減することである。

Status of This Memo

  • これは Internet Standards Track 文書である。
  • 本書は Internet Engineering Task Force（IETF）の成果物である。本書は IETF コミュニティの合意を表している。公開レビューを受け、Internet Engineering Steering Group（IESG）により公開が承認されている。Internet Standards に関する追加情報は RFC 5741 の Section 2 にある。
  • 本書の現状、正誤表、フィードバック提供方法に関する情報は、以下から入手できる。
    • http://www.rfc-editor.org/info/rfc7644
  • Copyright (c) 2015 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.
  • 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.

Table of Contents

1. Introduction and Overview

SCIM プロトコルは、Web 上および、企業からクラウドのサービスプロバイダへの連携やクラウド間シナリオといったクロスドメイン環境において、アイデンティティデータをプロビジョニングおよび管理するための、アプリケーションレベルの HTTP ベースのプロトコルである。本プロトコルは、Users や Groups といった中核となるアイデンティティリソースに加え、カスタムリソースおよびリソース拡張の作成、変更、取得、探索を支援する。

リソース、属性、および全体スキーマの定義は、SCIM Core Schema 文書 [RFC7643] に定義されている。

1.1. Intended Audience

本書は、SCIM HTTP サービスプロバイダと、サービスプロバイダに情報をプロビジョニングしたり、そこから情報を取得したりする可能性のある HTTP クライアントの双方に向けて、SCIM プロトコルの利用方法を案内することを意図している。

1.2. Notational Conventions

  • 本書中の「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」というキーワードは、[RFC2119] に記載のとおりに解釈する。
    • これらのキーワードは要件等を曖昧さなく規定する場合は大文字で表記される。
    • 大文字で表記されない場合は自然言語としての意味で用いられる。
  • 可読性のため、本書の例は URL エンコードされていない。実装者は [RFC3986] Section 2.1 に従い URL をパーセントエンコードしなければならない。
  • 図や例の URI は、空白・余分な改行を含むことがあり、また「...」で短縮されている場合がある。

1.3. Definitions

本仕様は [RFC7643] の定義を使用し、以下の追加用語を定義する。

Base URI

  • SCIM HTTP プロトコルは Base URI からの相対パスとして記述される。
  • Base URI はクエリ文字列を含んではならない（クライアントが追加のパスやクエリを付加するため）。
  • Base URI は URL であり、多くの場合 https スキーム、ドメイン名、初期パスから構成される [RFC3986]。

例:

https://example.com/scim/

補足:

  • 本書の例は、SCIM サービスルートとサーバールートが同一（パスプレフィックスなし）であることを前提とする。
  • SCIM サーバーは任意の URI パスプレフィックスでデプロイされ得る（例: https://example.com/ や https://example.com/scim/tenancypath/）。
  • クライアントはサーバールートのプレフィックスにバージョン番号を適用してもよい（Section 3.13）。

2. Authentication and Authorization

SCIM プロトコルは HTTP を基盤としており、SCIM 固有の認証・認可方式をそれ自体で定義しない。SCIM は、TLS および／または [RFC7235] に従う標準的な HTTP の認証・認可方式の利用に依存する。例えば（これらに限らない）:

方式の例

TLS Client Authentication

  • サービスプロバイダは TLS クライアント認証（相互認証）を要求してもよい。([RFC5246] Section 7.3)

HOBA Authentication

  • HTTP Origin-Bound Authentication（HOBA）は TLS クライアント認証の派生であり、デジタル署名ベースの HTTP 認証方式。([RFC7486])
  • HTML に埋め込まれた JavaScript ベースの認証にも使用できる。
  • パスワードを要求する方式の代替となり、パスワード漏えい等の問題を回避する。

Bearer Tokens

  • Bearer tokens [RFC6750] は TLS や OAuth 2.0 [RFC6749] と組み合わせて使用してもよい。
  • 認証が弱い／ない状態で発行されたトークンは、（匿名登録等の単回使用を除き）使用すべきではない（Section 3.3 参照）。
  • セキュリティ考慮事項は Section 7.4 を参照。
  • サービスプロバイダは bearer token を検証・解析・または introspect できる方法を持たなければならない（具体的方法は本仕様のスコープ外）。

PoP Tokens

  • proof-of-possession（PoP）token は、提示者が特定の鍵を保持していることを暗号学的に示す。
  • 例や利用は [OAuth-PoP-Arch] を参照。

Cookies

  • JavaScript クライアントは TLS 上で認証状態を含む HTTP cookie を提示してもよい。([RFC6265])
  • SCIM の目的においては Section 7.4 の考慮事項が適用される。

Basic Authentication

  • 単一要素の固定秘密に基づくため利用は避けるべき。
  • 使うなら他要素と組み合わせるべき。
  • セキュリティ考慮事項は [HTTP-BASIC-AUTH] に詳しい。

要件・運用上の注意

  • [RFC7235] Section 4.1 に従い、サービスプロバイダはサポートする HTTP 認証方式を WWW-Authenticate ヘッダーにより示さなければならない。
  • 認証済みクライアントをアクセス制御ポリシーへ対応付けられなければならない（認可モデルはスコープ外）。
  • 主体は通常 Authorization ヘッダーから直接／間接に決定される。

例（説明用。bearer tokens 推奨を意図しない）:

GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8

2.1. Use of Tokens as Authorizations

  • OAuth により発行される認可グラントを表すトークン（bearer / PoP）を用いる場合、スコープや対応付くべき主体等を考慮してローカルのアクセス制御ルールを検討すべき。
  • [RFC7521] Section 6 の一般的シナリオ例:
    • クライアントがアサーションで認証する／自身として行動する
    • クライアントがユーザーの代わりに行動する
    • クライアントが匿名ユーザーの代わりに行動する（Section 2.2）
  • OAuth 認可トークン利用時は [RFC7521] Section 8 の脅威と対策を考慮しなければならない。

2.2. Anonymous Requests

  • 導入形態によっては未認証（匿名）のリクエストを許可することが受け入れ可能な場合がある。
  • 例: 匿名クライアントからの SCIM Create（Section 3.3）を受け入れるユーザー自己登録。
  • セキュリティ考慮事項は Section 7.6。

3. SCIM Protocol

3.1. Background

  • SCIM は HTTP [RFC7230] を基盤とする。
  • HTTP ヘッダーと URI とともに、JSON [RFC7159] ペイロードで SCIM リソースを伝達する。
  • プロトコル固有のメッセージ（リクエストパラメータ、エラー等）も JSON 本文でやり取りする。
  • メディアタイプ: application/scim+json（Section 8.1）。

Resource

  • SCIM の「resource」は JSON オブジェクトで、HTTP メソッドにより作成・維持・取得できる。
  • 各リソース表現は schemas 属性（1つ以上の URI リスト）を持ち、リソースに含まれる属性を示す SCIM スキーマを表す。
  • スキーマ定義は /Schemas endpoint から取得できる（[RFC7643] Section 8.7）。
  • クライアントは、属性スキーマがサービスプロバイダごとに異なり得ることを想定すべき。
  • PUT 例: readOnly 属性は無視され、readWrite 属性は更新される。クライアントが readOnly を発見して削除する必要はない。
  • サービスプロバイダは送信されたものと完全に同じスキーマ／値で返すことを期待されない。レスポンスはサービスプロバイダが解釈した状態を反映する。

Message

  • SCIM の「message」はリクエスト／レスポンスに関連するプロトコルパラメータを伝達する JSON オブジェクトで、schemas 属性を含む。
  • message の schemas URI は必ず urn:ietf:params:scim:api: で始まらなければならない。
  • SCIM message スキーマは固定的であるため、/Schemas endpoint により発見可能であってはならない。

検証に関する方針

  • クロスドメインでスキーマや実装が異なり得るため、文書検証（例: XML Schema）のような技法は推奨されない。
  • サービスプロバイダは自身のスキーマ文脈で解釈し、処理規則に従う。

3.2. SCIM Endpoints and HTTP Methods

SCIM は既知の endpoint と HTTP メソッドを規定する。

  • "User" / "Group" はそれぞれ /Users / /Groups に対応する。
  • 拡張リソースは、リソース名を複数形（末尾に s）にする慣例に従って endpoint を定義すべき。
  • 複数形が曖昧な場合があるため、クライアントは /ResourceTypes で endpoint を発見すべき。

SCIM HTTP Methods（Table 1）

HTTP Method SCIM Usage
GET 1つ以上の完全または部分的なリソースを取得する
POST endpoint に応じて、新規作成／検索リクエスト作成／一括変更に使用してよい
PUT 既存属性を指定された置換属性セットで置き換える（新規作成に使ってはならない）
PATCH 一連の変更でリソースを変更する（部分更新）
DELETE リソースを削除する

Defined Endpoints（Table 2）

Resource/Name Endpoint Operations Description
User /Users GET (3.4.1), POST (3.3), PUT (3.5.1), PATCH (3.5.2), DELETE (3.6) Users の取得、追加、変更
Group /Groups GET (3.4.1), POST (3.3), PUT (3.5.1), PATCH (3.5.2), DELETE (3.6) Groups の取得、追加、変更
Self /Me GET, POST, PUT, PATCH, DELETE (3.11) 認証済み主体に対応付くリソース操作のエイリアス
Service provider config /ServiceProviderConfig GET (4) サービスプロバイダ設定の取得
Resource type /ResourceTypes GET (4) サポートされるリソース種別の取得
Schema /Schemas GET (4) サポートされるスキーマの取得
Bulk /Bulk POST (3.7) 一括更新
Search [prefix]/.search POST (3.4.3) POST により 1つ以上のリソース種別を検索
  • すべてのリクエストは Base URL から導出された URL に対して行う。
  • レスポンスは JSON の HTTP 本文。
  • エラーは可能であれば HTTP ステータスコードとして送信し、本文にも記載すべき（Section 3.12）。

3.3. Creating Resources

  • 新規リソース作成: リソース種別 endpoint（例: /Users, /Groups）に HTTP POST。

mutability 規則

  • readOnly は無視されなければならない。
  • readWrite で省略された属性は「主張されていない」とみなしてよい（既定値割当も可）。
  • 主張されていない属性を既定値にするかは、クライアントがすべての属性へアクセスできるか等を考慮してよい。
  • 既存値や既定値を上書きしたい場合:
    • 単一値属性: null
    • 複数値属性: 空配列 []\ を指定して値を消去してよい。

成功・衝突

  • 成功: HTTP 201 (Created) を返さなければならない。
  • レスポンス本文には新規作成リソース表現を含めるべき。
  • 作成リソース URI は Location ヘッダーと本文の meta.location に含めなければならない。
  • 衝突（例: userName 重複）: HTTP 409 (Conflict) と scimType = uniqueness を返さなければならない。

例: User 作成（Request）

POST /Users  HTTP/1.1
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  }
}

例: User 作成（Response）

HTTP/1.1 201 Created
Content-Type: application/scim+json
Location: https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"

{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "externalId":"bjensen",
  "meta":{
    "resourceType":"User",
    "created":"2011-08-01T21:32:44.882Z",
    "lastModified":"2011-08-01T21:32:44.882Z",
    "location":"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W/\"e180ee84f0671b1\""
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen"
}

3.3.1. Resource Types

  • endpoint にリソースを追加する際、meta.resourceType は当該 endpoint のリソース種別としてサービスプロバイダが設定しなければならない。
    • /Users へ POST → "User"
    • /Groups へ POST → "Group"

3.4. Retrieving Resources

  • 不透明で一意な URL、またはクエリ（Section 3.4.2）で取得してよい。
  • 返却属性はサーバーの属性スキーマとリクエストパラメータで決まる。
  • 既定では returned が always または default の属性が返される。

3.4.1. Retrieving a Known Resource

  • 既知リソース取得: GET /Users/{id}, GET /Groups/{id}, GET /Schemas/{id}。
  • 存在する場合: HTTP 200 (OK) と本文に結果。

例: User 取得（Request）

GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

例: User 取得（Response）

HTTP/1.1 200 OK
Content-Type: application/scim+json
Location: https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"f250dd84f0671c3"

{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "externalId":"bjensen",
  "meta":{
    "resourceType":"User",
    "created":"2011-08-01T18:29:49.793Z",
    "lastModified":"2011-08-01T18:29:49.793Z",
    "location":"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W/\"f250dd84f0671c3\""
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen",
  "phoneNumbers":[{"value":"555-555-8377","type":"work"}],
  "emails":[{"value":"bjensen@example.com","type":"work"}]
}

3.4.2. Query Resources

SCIM はフィルタ／ソート／ページネーション等に使用できる標準クエリパラメータ集合を定義する。

  • クエリは以下に対して実行してよい:
    • 単一リソース
    • リソース種別 endpoint（例: /Users）
    • サービスプロバイダ Base URI
  • 追加のクエリパラメータをサポートしてもよい。
  • 未認識のクエリパラメータがあっても拒否せず無視すべき。

ListResponse スキーマと属性

  • レスポンス schemas:
    • urn:ietf:params:scim:api:messages:2.0:ListResponse

属性:

  • totalResults（必須）: 結果の総数（返却件数より大きいことがある）。
  • Resources（totalResults が 0 でない場合必須）: リソースの複数値リスト（ページング時は部分集合）。
  • startIndex（ページングで部分結果の場合必須）: 1始まりの開始位置。
  • itemsPerPage（ページングで部分結果の場合必須）: 1ページの返却件数。
  • 一致 0 件でも HTTP 200 で totalResults: 0 を返さなければならない。

例: userName だけ取得（Request）

GET /Users?attributes=userName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

例: userName だけ取得（Response）

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 2,
  "Resources": [
    { "id": "2819c223-7f76-453a-919d-413861904646", "userName": "bjensen" },
    { "id": "c75ad752-64ae-4823-840d-ffa80929976c", "userName": "jsmith" }
  ]
}

NOTE: "id" は returned 特性が always のため返る。

3.4.2.1. Query Endpoints

クエリ対象例:

  • /Users/{id}
  • /Users
  • /Groups

サーバールートに対するクエリ:

  • フィルタ対象としてサーバー内のすべてのリソースを含む。
  • meta.resourceType によるフィルタで特定種別に限定してよい。

例:

filter=(meta.resourceType eq User) or (meta.resourceType eq Group)
  • 結果が多すぎる場合、HTTP 400 と scimType: "tooMany" で拒否しなければならない。

3.4.2.2. Filtering

  • Filtering は OPTIONAL。
  • クライアントは /ServiceProviderConfig の filter 属性でサポート状況を把握できる。
  • filter クエリパラメータにフィルタ式を指定でき、指定された場合は一致リソースのみ返されなければならない。
  • 属性名と属性演算子は大文字小文字を区別しない。

例（同義）:

filter=userName Eq "john"
filter=Username eq "john"
  • filter は少なくとも 1 つの有効な式を含まなければならない。
  • 複数式は論理演算子で結合でき、() でグループ化できる。
  • [] による複合属性フィルタ（Complex attribute filter grouping）はサービスプロバイダがサポートしてもよい。
Attribute Operators（Table 3）
Operator Description Behavior（要旨）
eq equal 属性値と演算子値が完全一致で一致
ne not equal 同一でない
co contains 演算子値が属性値の部分文字列
sw starts with 演算子値が属性値の先頭に一致（完全一致含む）
ew ends with 演算子値が属性値の末尾に一致（完全一致含む）
pr present 空/null でない、または複合属性に空でないノードがある
gt/ge/lt/le greater/greater or equal/less/less or equal 型に応じた比較（Boolean/Binary は invalidFilter で 400）
Logical Operators（Table 4）
Operator Description Behavior
and Logical "and" 両方 true の場合のみ一致
or Logical "or" どちらか true で一致
not "Not" function 式が false の場合に一致
Grouping Operators（Table 5）
Operator Description Behavior
( ) Precedence grouping グループ化で演算順序変更
[ ] Complex attribute filter grouping 親属性の同一値に対して角括弧内式を適用（ネスト可）
ABNF（SCIM Filters）
FILTER    = attrExp / logExp / valuePath / *1"not" "(" FILTER ")"

valuePath = attrPath "[" valFilter "]"
            ; FILTER uses sub-attributes of a parent attrPath

valFilter = attrExp / logExp / *1"not" "(" valFilter ")"

attrExp   = (attrPath SP "pr") /
            (attrPath SP compareOp SP compValue)

logExp    = FILTER SP ("and" / "or") SP FILTER

compValue = false / null / true / number / string
            ; rules from JSON (RFC 7159)

compareOp = "eq" / "ne" / "co" /
                   "sw" / "ew" /
                   "gt" / "lt" /
                   "ge" / "le"

attrPath  = [URI ":"] ATTRNAME *1subAttr
            ; SCIM attribute name
            ; URI is SCIM "schema" URI

ATTRNAME  = ALPHA *(nameChar)

nameChar  = "-" / "_" / DIGIT / ALPHA

subAttr   = "." ATTRNAME
            ; a sub-attribute of a complex attribute

評価順序（優先順位が高い順）:

  1. グループ化演算子
  2. 論理演算子（not > and > or）
  3. 属性演算子

補足:

  • 複数値属性は、いずれかの値が一致すればリソース全体が一致。
  • 複合属性は完全修飾されたサブ属性（例: name.givenName）を指定。
  • 未サポート操作の場合、HTTP 400 と scimType: "invalidFilter" を返さなければならない（例: regex）。
  • 文字列比較の大小文字扱いは属性の caseExact 特性に従う。
  • schemas を含むフィルタ式でスキーマ／拡張によりクエリしてよい。
Example Filters（Figure 2）
filter=userName eq "bjensen"
filter=name.familyName co "O'Malley"
filter=userName sw "J"
filter=urn:ietf:params:scim:schemas:core:2.0:User:userName sw "J"
filter=title pr
filter=meta.lastModified gt "2011-05-13T04:42:34Z"
filter=meta.lastModified ge "2011-05-13T04:42:34Z"
filter=meta.lastModified lt "2011-05-13T04:42:34Z"
filter=meta.lastModified le "2011-05-13T04:42:34Z"
filter=title pr and userType eq "Employee"
filter=title pr or userType eq "Intern"
filter=schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
filter=userType eq "Employee" and (emails co "example.com" or emails.value co "example.org")
filter=userType ne "Employee" and not (emails co "example.com" or emails.value co "example.org")
filter=userType eq "Employee" and (emails.type eq "work")
filter=userType eq "Employee" and emails[type eq "work" and value co "@example.com"]
filter=emails[type eq "work" and value co "@example.com"] or ims[type eq "xmpp" and value co "@foo.com"]

3.4.2.3. Sorting

  • Sort は OPTIONAL。
  • サポートは /ServiceProviderConfig の sort 属性で把握できる。
  • sortBy と sortOrder の組み合わせで順序指定。

sortBy:

  • ソートに用いる属性。
  • 複数値属性: primary があればその値、なければ先頭値でソート。
  • 複合属性: name.givenName のようにサブ属性パスを指定。
  • データが存在しない場合は、昇順で末尾、降順で先頭に並ぶ。

sortOrder:

  • ascending / descending。
  • sortBy が指定され sortOrder が省略された場合、既定は ascending。
  • 大文字小文字扱い等は属性型（case-exact かどうか等）に従う。

3.4.2.4. Pagination

  • 大量リソースをページングするためのパラメータ。
  • 状態を保持しない（同じクエリでもリソース変化により結果が変わり得る）。
  • OpenSearch Protocol [OpenSearch] に由来。

Pagination Request Parameters（Table 6）:

Parameter Description Default
startIndex 1始まりの開始位置。1未満は1として扱う 1
count 0以上の整数。望ましい最大件数。負は0扱い。0は totalResults を除き結果を返さない なし（指定時は超えて返してはならない。少なく返してもよい。未指定時はサーバー設定）

Pagination Response Elements（Table 7）:

Element Description
itemsPerPage 0以上の整数。1ページの返却件数
totalResults 0以上の整数。総一致件数
startIndex 1始まりの開始位置

例: 最初の10件取得

GET /Users?startIndex=1&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

レスポンス例（リソース省略）:

{
  "totalResults": 100,
  "itemsPerPage": 10,
  "startIndex": 1,
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "Resources": [{ "...": "..." }]
}

続きは startIndex=11&count=10。

3.4.2.5. Attributes

以下の OPTIONAL パラメータで返却属性を制御（ただしサービスプロバイダはサポートしなければならない）。

  • attributes: 返す属性名のリスト（既定返却集合を上書き）。属性名は標準属性表記（Section 3.10）。
  • excludedAttributes: 既定返却集合から除外する属性名リスト。returned: "always" の属性には影響しない。属性名は標準属性表記（Section 3.10）。

3.4.3. Querying Resources Using HTTP POST

  • /.search パス拡張と POST を使い、URL パラメータなしでクエリしてよい。
  • 有効な SCIM endpoint 末尾に /.search を含めることで、POST がクエリを意図することを示す。

SearchRequest スキーマと属性

  • リクエスト schemas:
    • urn:ietf:params:scim:api:messages:2.0:SearchRequest

属性（いずれも OPTIONAL）:

  • attributes
  • excludedAttributes
  • filter
  • sortBy
  • sortOrder
  • startIndex
  • count

例: POST によるクエリ（Request）

POST /.search
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
  "attributes": ["displayName", "userName"],
  "filter": "displayName sw \"smith\"",
  "startIndex": 1,
  "count": 10
}

例: POST によるクエリ（Response）

HTTP/1.1 200 OK
Content-Type: application/scim+json
Location: https://example.com/.search

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults":100,
  "itemsPerPage":10,
  "startIndex":1,
  "Resources":[
    {"id":"2819c223-7f76-413861904646","userName":"jsmith","displayName":"Smith, James"},
    {"id":"c8596b90-7539-4f20968d1908","displayName":"Smith Family"},
    ...
  ]
}

3.5. Modifying Resources

  • PUT または PATCH で変更できる（全体置換／部分更新）。
  • 実装者は HTTP PUT をサポートしなければならない。
  • 大きくなり得るリソース（例: Groups）のため、PATCH をサポートすべき。
  • PATCH のサポート有無は /ServiceProviderConfig で把握できる。

3.5.1. Replacing with PUT

  • PUT は属性を置換するために使用。
  • リソース識別子はサービスプロバイダが割当てるため、PUT は新規作成に使用してはならない。

mutability 規則（PUT）

  • readWrite, writeOnly: 提供値で既存値を置換。
    • readWrite で省略された属性は主張されていないとみなしてよい（削除 or 既定値割当など）。
    • 既定値上書き目的で単一値 null、複数値 [] で消去してよい。
  • immutable: 既に値がある場合は一致しなければならない。違えば HTTP 400 と scimType: "mutability" を返すべき。
  • readOnly: 提供値は無視されなければならない。
  • required 属性は PUT で指定しなければならない。

成功時レスポンス

  • 特に指定がない限り 200 OK とリソース全体を返す。

例（Request / Response）は原文のブロックを参照（PUT /Users/...）。

3.5.2. Modifying with PATCH

  • PATCH は OPTIONAL。
  • クライアントは add / remove / replace の操作列で更新できる。
  • SCIM PATCH は JSON Patch [RFC6902] に基づくが、配列インデックスや move 等の操作をサポートしない。

PatchOp 形式（概要）

  • schemas に urn:ietf:params:scim:api:messages:2.0:PatchOp を含めなければならない。
  • Operations 配列（1つ以上）を含めなければならない。
  • 各 operation は op（add/remove/replace）をちょうど1つ持つ。

例（非規範）:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "add",
      "path": "members",
      "value": [
        {
          "display": "Babs Jensen",
          "$ref": "https://example.com/v2/Users/2819c223...413861904646",
          "value": "2819c223-7f76-453a-919d-413861904646"
        }
      ]
    }
  ]
}

path のルール

  • path は対象属性パスを表す string。
  • add / replace は OPTIONAL、remove は REQUIRED。

ABNF:

PATH = attrPath / valuePath [subAttr]

有効な例（抜粋）:

members
name.familyName
addresses[type eq "work"]
members[value eq "2819c223-..."]
members[value eq "2819c223-..."].displayName

処理上の要点

  • 操作はスキーマと mutability に適合しなければならない（不適合なら 3.12 に従うエラー）。
  • schemas 属性の変更が行われた場合、後続操作は変更後の状態を前提とする。
  • Operations 配列順に逐次適用し、各操作結果が次操作の対象になる。
  • primary: true を立てると、他の値の primary を false にリセットさせなければならない。
  • PATCH は原子的（atomic）。途中で失敗したら元に戻し、失敗を返す。
  • 成功時:
    • 200 OK + 本文でリソース全体、または 204 No Content。
    • リクエストで attributes が指定されている場合は 200 OK を返さなければならない。

3.5.2.1. Add Operation（要点）

  • value 必須。
  • path 省略時はリソース自身への属性追加。
  • 対象が複数値属性なら追加、単一値属性なら置換など、対象位置により挙動が決まる。
  • 既に同一値がある場合は変更しないべきで、成功を返すべき。

（以降、Add の具体例：Group への member 追加、User への属性追加）

3.5.2.2. Remove Operation（要点）

  • path 必須。なければ HTTP 400 + scimType: "noTarget"。
  • 対象が単一値／複数値（フィルタ有無）／複合複数値などに応じて削除挙動が変わる。
  • 削除により必須属性や readOnly 属性が未割当になる場合、HTTP エラー + scimType: "mutability" を返さなければならない。

（以降、Remove の具体例：Group から member 削除、members 全削除、emails 条件削除、削除+追加 など）

3.5.2.3. Replace Operation（要点）

  • path 省略時はリソース自身が対象で value は置換属性集合を含む必要。
  • 単一値は置換、複数値は（フィルタなしなら）全置換。
  • 存在しない属性への replace は add として扱わなければならない。
  • valuePath フィルタで一致が得られない場合は HTTP 400 + scimType: "noTarget" を返して失敗を示さなければならない。

（以降、Replace の具体例：members 全置換、addresses[type eq "work"] 置換、特定 subAttr 置換、複数属性値の置換）

3.6. Deleting Resources

  • クライアントは DELETE で削除を要求する。
  • サービスプロバイダは恒久削除しないことを選択してもよいが、削除済みリソースに関連する操作には 404 を返さなければならない。
  • 将来のクエリ結果から除外しなければならない。
  • 削除済みリソースは衝突計算に考慮すべきではない（例: 同じ userName の CREATE を 409 にすべきではない）。

例（Request）:

DELETE /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8
If-Match: W/"c310cd84f0281b7"

成功時:

  • HTTP 204 No Content を返さなければならない。

削除済み User 取得例:

GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8

レスポンス例:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "detail": "Resource 2819c223-7f76-453a-919d-413861904646 not found",
  "status": "404"
}

3.7. Bulk Operations

  • Bulk operation は OPTIONAL。
  • 単一リクエストで大量のリソース操作集合を送信可能にする。
  • サポートは /ServiceProviderConfig で把握できる。
  • 本文は POST/PUT/PATCH/DELETE を用いるリソース操作集合を含む。

BulkRequest / BulkResponse

  • Bulk リクエスト schemas:
    • urn:ietf:params:scim:api:messages:2.0:BulkRequest
  • Bulk レスポンス schemas:
    • urn:ietf:params:scim:api:messages:2.0:BulkResponse

属性

  • failOnErrors（Request: OPTIONAL / Response: 無効）
    • エラー上限（この数に達したら打ち切り）
  • Operations（必須）: 各操作の配列。各要素のサブ属性:
    • method（必須）: "POST" | "PUT" | "PATCH" | "DELETE"
    • bulkId（POST の場合必須）: 一時識別子（bulk 内で一意）
    • version（条件付き）: ETag を使う場合に "PUT"/"PATCH"/"DELETE" で使用してよい
    • path（Request: 必須）:
      • POST: /Users や /Groups の endpoint
      • それ以外: /Users/{id} のように特定リソースへのパス
    • data（Request: method が POST/PUT/PATCH の場合必須）: リソースデータ
    • location（Response: POST失敗以外は必須）: リソース URL
    • response（Response: 非2xx時は必須）: 詳細レスポンス本文（成功時は省略可）
    • status（必須）: HTTP レスポンスコード（非2xx時は詳細エラーを含める）
  • bulk が正常に処理された場合は HTTP 200 OK を返さなければならない。そうでない場合は適切な HTTP エラーコード。
  • サービスプロバイダは可能な限り処理を継続し部分的失敗を無視しなければならない（ただし failOnErrors で上書き可）。
  • 受信した operation 並びを最適化することを選択してもよいが、同じ状態遷移結果を保証しなければならない。

3.7.1. Circular Reference Processing

  • bulk ジョブ内の循環参照解決を試みなければならない。
  • 失敗した場合、HTTP 409 (Conflict) を返してもよい。
  • 例: Group A が Group B を参照し、Group B が Group A を参照するケース。

3.7.2. "bulkId" Temporary Identifiers

  • 新規 "User" と新規 "Group" を作成し、新規 User を新規 Group に追加する、といった参照のために bulkId を使用する。
  • 参照時は "bulkId:" を前置（例: bulkId:qwerty）。
  • サービスプロバイダは作成後、この文字列を恒久的なリソース id に置換しなければならない。
  • 各リクエストに固有の bulkId を指定する。

（例: Alice の作成と Tour Guides グループ作成、members に bulkId 参照、レスポンスで id 対応付けなど）

3.7.3. Response and Error Handling

  • レスポンスは処理されたすべての operation の結果を含めなければならない。
  • location は失敗した POST（locationがない）を除くすべてで返さなければならない。
  • status は code（必須）と、エラー時は description を含めなければならない。
  • エラー時の response は詳細エラー（Section 3.12）を含める。

失敗例（抜粋）:

{
  "status": "400",
  "response": {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "scimType": "invalidSyntax",
    "detail": "Request is unparsable, syntactically incorrect, or violates schema.",
    "status": "400"
  }
}

3.7.4. Maximum Operations

  • サービスプロバイダは単一リクエストの最大 operation 数と最大ペイロードサイズを定義しなければならない。
  • 上限は /ServiceProviderConfig から取得してよい（bulk 関連）。
  • 超過時は HTTP 413 (Payload Too Large) を返さなければならない。
  • レスポンス本文で超過した上限を指定しなければならない。

例（抜粋）:

HTTP/1.1 413 Payload Too Large
Content-Type: application/scim+json

{
  "schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "413",
  "detail":"The size of the bulk operation exceeds the maxPayloadSize (1048576)."
}

3.8. Data Input/Output Formats

概要

  • サーバーは UTF-8 エンコーディング（[RFC3629]）を使用する JSON 構造のレスポンスを受け付け、返せなければならない。
  • UTF-8 は既定のエンコーディング形式としなければならない。
  • その他のメディアタイプはサービスプロバイダがサポートしてもよいが、本仕様のスコープ外。

Content-Type / Accept による指定

  • 他のエンコーディングを使用するクライアントは、HTTP Content-Type ヘッダー（[RFC7231] Section 3.1.1.5）で提出形式を指定しなければならない。
  • クライアントは（[RFC7231] Section 5.3.2 に従い）HTTP Accept ヘッダーで望ましいレスポンス形式を指定してもよい。
    • 例: Accept: application/scim+json
  • 代替として URI サフィックスでもよい。

例: URI サフィックス

GET /Users/2819c223-7f76-453a-919d-413861904646.scim
Host: example.com

サポート必須・推奨の Accept

  • サービスプロバイダは Accept: application/scim+json をサポートしなければならない。
  • また、[RFC7159] に適合する JSON 文書を指定する Accept: application/json もサポートすべき。
  • 形式が指定されない場合、既定は application/scim+json。

JSON 表現の基本形

単一属性（文字列の name-value ペア）

"attribute": "value"

複数値属性（配列）

"attributes": [ "value1", "value2" ]

ネスト要素を持つ要素（オブジェクト）

"attribute": { "subattribute1": "value1", "subattribute2": "value2" }

3.9. Additional Operation Response Parameters

レスポンスで返される属性集合

  • リソース表現が返される SCIM 操作（例: HTTP GET）では、返される属性は次により定義される。
    • 最小属性集合 (minimum set)
      • "returned" 特性が "always" の属性から構成（[RFC7643] Section 2.2）。
    • 既定属性集合 (default set)
      • "returned" 特性が "default" の属性から構成。

部分的なリソース表現の要求（相互排他的）

クライアントは、レスポンスでリソースが返される任意の操作において、相互排他的な URL クエリパラメータのいずれかを指定してよい。

  • attributes
  • excludedAttributes

attributes

  • 指定された場合、既定の属性リストは上書きされる。
  • 各リソースは次を含まなければならない:
    • 最小属性集合
    • attributes で明示的に要求された属性またはサブ属性
  • 値は、標準の属性表記（Section 3.10）による リソース属性名のカンマ区切り（例: userName,name,emails）。

excludedAttributes

  • 指定された場合、各リソースは 最小属性集合を必ず含む。
  • 加えて、既定属性集合から excludedAttributes に列挙された属性を除いた集合が返される。
  • 値は、標準の属性表記（Section 3.10）による リソース属性名のカンマ区切り（例: userName,name,emails）。

例: attributes による部分取得

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

例: レスポンス

HTTP/1.1 200 OK
Content-Type: application/scim+json
Location: https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "userName": "bjensen"
}

3.10. Attribute Notation

共通スキーム

  • すべての操作は、単純属性および複合属性を参照するための共通スキームを共有する。

完全修飾（Fully Qualified）識別

  • 一般に属性は、スキーマ URN + ":" + 属性名 で一意に識別される。
    • 例: core User の userName
      • urn:ietf:params:scim:schemas:core:2.0:User:userName

URN プレフィックス省略の可否

  • クライアントは core schema 属性の URN プレフィックスを省略してもよい。
  • ただし拡張属性は命名衝突を避けるため、関連するスキーマ拡張 URN で完全修飾すべき。
    • 例: urn:ietf:params:scim:schemas:exampleCo:2.0:hr の age
      • urn:ietf:params:scim:schemas:exampleCo:2.0:hr:age

複合属性のサブ属性参照（ドット表記）

  • 複合属性のサブ属性は ドット（.）による入れ子表記で参照される。
    • 形式: {urn}:{Attribute name}.{Sub-Attribute name}
    • 例: User の name.givenName
      • urn:ietf:params:scim:schemas:core:2.0:User:name.givenName

大文字小文字

  • 完全エンコードされた属性名の各要素（URN、属性名、サブ属性名）は 大文字小文字を区別しない。

3.11. "/Me" Authenticated Subject Alias

概要

  • クライアントは、任意の SCIM 操作において、現在認証されている主体に関連付く User（または他のリソース）に対する URI エイリアスとして <base-URI>/Me を使用してよい。

サービスプロバイダの応答（3 通り）

  1. 未サポートの場合
    • HTTP 501 (Not Implemented) で応答すべき。
  2. リダイレクトしてもよい
    • HTTP 308 (Permanent Redirect) でリダイレクトし、認証済み主体に関連付くリソースへ誘導してもよい。
    • クライアントは指定された Location でリクエストを繰り返してよい。
  3. 直接処理してもよい
    • SCIM リクエストをそのまま処理してもよい。
    • いずれの場合も、HTTP Location ヘッダーは エイリアス先リソースの恒久 locationでなければならない。

"/Me" と Create（POST）

  • "/Me" エイリアスを用いて SCIM Create Resource（HTTP POST）を行う場合、作成される望ましい resourceType は、以下に基づきサービスプロバイダ裁量で決定される。
    • 認証済み主体（匿名でない場合）
    • 任意の本文属性（例: "schemas"）
  • セキュリティ上の考慮: Section 7.6 参照。

3.12. HTTP Status and Error Response Handling

概要

  • SCIM は、成功/失敗の通知に [RFC7231] Section 6 の HTTP ステータスコードを使用する。
  • さらに、失敗時にはレスポンス本文で JSON 形式のエラーを返さなければならない。
  • エラーは次の schema URI で識別される:
    • urn:ietf:params:scim:api:messages:2.0:Error

SCIM エラーレスポンス属性

  • status（必須）
    • JSON 文字列として表現される HTTP ステータスコード（[RFC7231] Section 6）。
  • scimType（任意）
    • SCIM 詳細エラーキーワード（Table 9）。
  • detail（任意）
    • 詳細な人間可読メッセージ。

ステータスコードの扱い（Table 8）

  • 307 Temporary Redirect（GET/POST/PUT/PATCH/DELETE）
    • 示された location で同一リクエストを繰り返す。
    • レスポンスで提供された location を恒久参照として使わず、元の URI を使い続けるべき（[RFC7231]）。
  • 308 Permanent Redirect（GET/POST/PUT/PATCH/DELETE）
    • 示された location で同一リクエストを繰り返す。
    • 提供された location を恒久参照として使用すべき（[RFC7538]）。
  • 400 Bad Request（GET/POST/PUT/PATCH/DELETE）
    • 解析不能、構文誤り、またはスキーマ違反。
  • 401 Unauthorized（GET/POST/PUT/PATCH/DELETE）
    • 認可失敗。Authorization ヘッダーが不正または欠落。
  • 403 Forbidden（GET/POST/PUT/PATCH/DELETE）
    • 供給された認可に基づき操作が許可されない。
  • 404 Not Found（GET/POST/PUT/PATCH/DELETE）
    • 指定リソースまたは endpoint が存在しない。
  • 409 Conflict（POST/PUT/PATCH/DELETE）
    • 指定 version が最新と不一致、または重複作成を拒否。
  • 412 Precondition Failed（PUT/PATCH/DELETE）
    • 更新に失敗。サーバー上でリソースが変更された。
  • 413 Payload Too Large（POST）
    • 例: {"maxOperations":1000,"maxPayloadSize":1048576}
  • 500 Internal Server Error（GET/POST/PUT/PATCH/DELETE）
    • 内部エラー。説明的なデバッグ助言を提供すべき。
  • 501 Not Implemented（GET/POST/PUT/PATCH/DELETE）
    • サービスプロバイダが要求操作（例: PATCH）をサポートしない。

400 Bad Request の詳細エラー種別（Table 9）

  • invalidFilter
    • フィルタ構文不正（Figure 1 不適合）または比較組み合わせが未サポート。
    • 適用: GET (3.4.2), POST(Search 3.4.3), PATCH(Path Filter 3.5.2)
  • tooMany
    • フィルタが過大な結果を生む。例: (userName pr)
    • 適用: GET (3.4.2), POST(Search 3.4.3)
  • uniqueness
    • 属性値が使用中または予約済み。
    • 適用: POST(Create 3.3), PUT(3.5.1), PATCH(3.5.2)
  • mutability
    • 属性の mutability または状態と両立しない変更。例: immutable 変更。
    • 適用: PUT(3.5.1), PATCH(3.5.2)
  • invalidSyntax
    • 本文メッセージ構造が不正、またはスキーマ不適合。
    • 適用: POST(Search 3.4.3 / Create 3.3 / Bulk 3.7), PUT(3.5.1)
  • invalidPath
    • "path" が不正または不正形式（Figure 7）。
    • 適用: PATCH(3.5.2)
  • noTarget
    • "path" が操作可能な属性/値を得られない（不一致フィルタ含む場合など）。
    • 適用: PATCH(3.5.2)
  • invalidValue
    • 必須値欠落、または型/スキーマと不整合。
    • 適用: GET(3.4.2), POST(Create 3.3 / Query 3.4.3), PUT(3.5.1), PATCH(3.5.2)
  • invalidVers
    • SCIM プロトコル version が未サポート（3.13）。
    • 適用: GET(3.4.2), POST(ALL), PUT(3.5.1), PATCH(3.5.2), DELETE(3.6)
  • sensitive
    • リクエスト URI に機微情報が渡され完了できない（7.5.2）。
    • 適用: GET(3.4.2)

Table 9 の Applicability は通常の HTTP メソッド向けだが、SCIM bulk operation（HTTP POST）内でも適用され得る。

エラー例

例: 存在しない GET（404）

HTTP/1.1 404 Not Found

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "detail": "Resource 2819c223-7f76-453a-919d-413861904646 not found",
  "status": "404"
}

例: PUT（400 / mutability）

HTTP/1.1 400 Bad Request

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "scimType": "mutability",
  "detail": "Attribute 'id' is readOnly",
  "status": "400"
}

3.13. SCIM Protocol Versioning

Base URL の version 指定

  • Base URL は、URL パスの独立セグメントとして version 識別子を付加してよい。
  • 本書の執筆時点では識別子は v2。
  • 指定する場合、version 識別子は リソース endpoint の直前に現れなければならない。
    • 形式: v + SCIM version 番号
    • 例: version v2 の User リクエスト: /v2/Users
  • version が指定された場合:
    • サービスプロバイダは 指定 version で操作を実行しなければならない、または 拒否しなければならない。
  • version が省略された場合:
    • サービスプロバイダは、サポートする 最新の SCIM プロトコル versionで操作を実行すべき。

3.14. Versioning Resources

ETag による versioning

  • SCIM は標準 HTTP ETags（[RFC7232] Section 2.3）によりリソース versioning をサポートする。
  • サービスプロバイダは、条件付き取得や意図しない上書き防止のために 弱い ETag を優先機構としてサポートしてよい。
  • サポートする場合:
    • SCIM ETags は HTTP ヘッダーとして指定されなければならない。
    • さらにリソースの meta.version にも指定すべき。

例: 作成（POST）と ETag 応答

リクエスト

POST /Users  HTTP/1.1
Host: example.com
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "bjensen",
  "externalId": "bjensen",
  "name": {
    "formatted": "Ms. Barbara J Jensen III",
    "familyName": "Jensen",
    "givenName": "Barbara"
  }
}

レスポンス（ヘッダー + meta に ETag）

HTTP/1.1 201 Created
Content-Type: application/scim+json
Location: https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "meta": {
    "resourceType": "User",
    "created": "2011-08-01T21:32:44.882Z",
    "lastModified": "2011-08-01T21:32:44.882Z",
    "location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
    "version": "W/\"e180ee84f0671b1\""
  },
  "name": {
    "formatted": "Ms. Barbara J Jensen III",
    "familyName": "Jensen",
    "givenName": "Barbara"
  },
  "userName": "bjensen"
}

条件付き取得（If-None-Match）

  • クライアントは返された ETag を用いて、変更があった場合にのみ取得してよい。
  • If-None-Match（[RFC7232] Section 3.2）を使用。

例

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
If-None-Match: W/"e180ee84f0671b1"
  • 変更なしの場合、サービスプロバイダは 304 (Not Modified) と 空の本文を返す。

更新時の整合性（If-Match）

  • versioning をサポートする場合、クライアントは PUT/PATCH に If-Match（[RFC7232] Section 3.1）を供給してよい。
  • 供給された ETag が最新リソースと一致する場合にのみ操作成功を保証できる。
    • 例: If-Match: W/"e180ee84f0671b1"

4. Service Provider Configuration Endpoints

概要

  • SCIM は、HTTP GET で取得できるサービスプロバイダ機能およびスキーマの発見を容易にするため、3 つの endpoint を定義する。

/ServiceProviderConfig

  • HTTP GET は、サービスプロバイダで利用可能な SCIM 仕様機能を記述する JSON を返す。
  • レスポンスは次を満たさなければならない:
    • "schemas" 属性に\ urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig を持つ JSON オブジェクト
  • 属性は [RFC7643] Section 5 で定義。
  • 表現例は [RFC7643] Section 8.5。

/Schemas

  • HTTP GET は、サービスプロバイダがサポートするリソーススキーマ情報を取得するために使用。
  • /Schemas への GET は、サポートされるすべてのスキーマを ListResponse 形式（Figure 3）で返さなければならない。
  • 個別スキーマは /Schemas にスキーマ URI を付加して取得する。
    • 例:
      • /Schemas/urn:ietf:params:scim:schemas:core:2.0:User
  • スキーマ内容は [RFC7643] Section 7、表現例は [RFC7643] Section 8.7。

/ResourceTypes

  • HTTP GET は、利用可能なリソース種別（例: Users / Groups）を発見するために使用。
  • 各 ResourceType は次を定義する:
    • endpoint
    • リソースを定義する core schema URI
    • サポートするスキーマ拡張
  • 属性定義は [RFC7643] Section 6、表現例は [RFC7643] Section 8.6。

ResourceType / Schema の単一取得と ListResponse

  • 特定の ResourceType または Schema へのリクエストでは、単一 JSON オブジェクトが Section 3.4.1 と同様に返される。
  • 複数の ResourceTypes または Schemas を返す場合:
    • urn:ietf:params:scim:api:messages:2.0:ListResponse のメッセージ形式を使用しなければならない（Figure 3 と Figure 9）。
  • フィルタリング、ソート、ページネーション等のクエリパラメータ（Section 3.4.2）は 無視されなければならない。
  • filter が提供された場合は、クライアントが誤って一致を仮定しないよう 403 (Forbidden) で応答すべき。

例: /ResourceTypes（非規範）

{
  "totalResults": 2,
  "itemsPerPage": 10,
  "startIndex": 1,
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "Resources": [{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
    "id": "User",
    "name": "User",
    "endpoint": "/Users",
    "description": "User Account",
    "schema": "urn:ietf:params:scim:schemas:core:2.0:User",
    "schemaExtensions": [{
      "schema": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
      "required": true
    }],
    "meta": {
      "location": "https://example.com/v2/ResourceTypes/User",
      "resourceType": "ResourceType"
    }
  }, {
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
    "id": "Group",
    "name": "Group",
    "endpoint": "/Groups",
    "description": "Group",
    "schema": "urn:ietf:params:scim:schemas:core:2.0:Group",
    "meta": {
      "location": "https://example.com/v2/ResourceTypes/Group",
      "resourceType": "ResourceType"
    }
  }]
}

5. Preparation and Comparison of Internationalized Strings

目的

  • 世界中の典型的ユーザーにとって納得のいく形で username/password の入力と比較が機能する可能性を高める。

規則（PRECIS）

  • "userName" または "password" 属性の一意性を比較・評価する前に、サービスプロバイダは以下に基づく規則を使用しなければならない:
    • PRECIS フレームワーク [RFC7564]
    • [RFC7613] Section 3 および 4 の準備・強制・比較ルール
  • "Case Mapping vs. Case Preparation" の議論は [RFC7613] Section 3.4 を参照。

6. Multi-Tenancy

概要

  • 単一サービスプロバイダが複数クライアントに SCIM を公開する場合がある。
  • クライアント間でリソースを共有できる場合／できない場合があり、これらのシナリオを multi-tenancy と呼ぶ。
  • 各クライアントはサービスプロバイダの tenant と理解される（またはそれを代表すると理解される）。
  • クライアント自身も multi-tenanted であり得る。

一般的なケース

  1. すべてのクライアントがすべてのリソースを共有（tenancy なし）
  2. 各クライアントがプライベートなリソースサブセットを作成・アクセス（1 client : 1 Tenant）
  3. クライアント集合がリソース集合を共有（M clients : 1 Tenant）
  4. 1 クライアントが複数のプライベートなリソースサブセットを作成・アクセス（1 client : M Tenants）
  • サービスプロバイダは上記ケースの任意のサブセットを実装してよい。
  • Multi-tenancy は OPTIONAL。
  • SCIM は multi-tenancy 方式を定義しない。

SCIM が規定しない事項

  • Tenants の登録／プロビジョニング
  • クライアントサブセットと Tenants サブセットの関連付け
  • リクエスト／レスポンスデータに tenant を示すこと、またはクエリ主体となる Tenant を示すこと

6.1. Associating Clients to Tenants

  • サービスプロバイダは、Section 2 で議論した認証機構によりクライアントのアイデンティティを決定し、関連 Tenant を推定してよい。
  • クライアントが複数 Tenant と関連付く実装では、Tenant を明示指定するために次の方法のいずれかを用いてよい（{tenant_id} はサービスプロバイダ定義の一意識別子）。
    • URL プレフィックス
      • https://www.example.com/Tenants/{tenant_id}/v2/Users
    • サブドメイン
      • https://{tenant_id}.example.com/v2/Groups
    • HTTP ヘッダー
      • ヘッダーで提供される {tenant_id} をターゲット Tenant 指標として認識してもよい
  • 明示指定を許可する場合、tenant 間利用ユースケースを防止/許可するアクセス制御が適切に用意されていることを確認すべき。
  • 暗黙の Tenant と明示指定 Tenant が衝突し得る場合、優先順位を考慮すべき。

6.2. SCIM Identifiers with Multiple Tenants

  • multi-tenant 実装の考慮事項:
    • すべての Tenants のすべてのリソースで一意となる SCIM id を実装してもよいが必須ではない。
    • クライアント定義 externalId は、関連付く Tenant 範囲内でのみ一意であることが求められる。

7. Security Considerations

7.1. HTTP Considerations

  • SCIM は HTTP の上に載るため、HTTP（[RFC7230] Section 9）および関連仕様のセキュリティ考慮事項の影響を受ける。
  • [RFC7230] Section 2.7.1 に従い、SCIM クライアントは、HTTP URI 参照で "userinfo"（username/password）コンポーネント（および @ 区切り）を生成してはならない。

7.2. TLS Support Considerations

  • SCIM リソースには password を含む機微情報が含まれるため、クライアント/サービスプロバイダは transport-layer セキュリティ機構の利用を要求しなければならない。
  • SCIM サービスプロバイダは TLS 1.2（[RFC5246]）をサポートしなければならない。
  • 追加の transport-layer 機構をサポートしてもよい。
  • TLS 使用時、クライアントは [RFC6125] に従い TLS/SSL サーバーアイデンティティ検査を行わなければならない。
  • TLS 実装の考慮事項は [RFC7525]。

7.3. Authorization Token Considerations

  • OAuth 2.0（[RFC6749]）等の authorization tokens を使う場合、[RFC7521] Section 8 の脅威と対策を考慮しなければならない。
  • bearer token / cookie の保有者が読み取り・変更・削除権限を持ち得るため、ランダム推測攻撃を防ぐ十分なエントロピーを含まなければならない（[RFC6750] Section 5.2, [RFC6819] Section 5.1.4.2.2）。
  • bearer tokens / HTTP cookies は TLS を使用して交換されなければならない。
  • bearer tokens は限定された生存期間を持たなければならず、期限切れにより継続アクセスのために新トークン取得を強制する（OAuth 2.0 の refresh は [RFC6749] Section 6）。
  • HTTP cookie はブラウザセッションを超えて続くべきではなく、セッション cookie の expiry time を設定すべき（[RFC6265] Section 5.2.1）。
  • OAuth bearer tokens をサポートする実装は [RFC7521] の考慮事項を考慮する必要がある。
  • 既定の認証方式（HTTP Basic）の考慮事項は [HTTP-BASIC-AUTH] に十分記載されており、より強い認証方式の利用が推奨される。
  • 認証・認可の具体的手法の指定は SCIM のスコープ外（参考情報として提供）。

7.5. Privacy Considerations

7.5.1. Personal Information

  • SCIM Core Schema（[RFC7643]）は個人識別情報を含み得る属性や機微な個人データを含み得る属性を定義する。
  • [RFC7643] の Security Considerations にあるプライバシー考慮事項を考慮しなければならない。

7.5.2. Disclosure of Sensitive Information in URIs

  • HTTP GET のクエリフィルタで情報要求するクライアントは、URI 露出によりブラウザやサーバーログから漏えいし得る点を考慮すべき（[RFC7231] Section 9.4）。
  • 特に個人識別情報やプライバシー法で制限される情報では、最大限のセキュリティ/機密性確保のため HTTP POST でクエリすべき（Section 3.4.3）。
  • 機微情報を含むフィルタの GET を受け取ったサーバーは 403 で応答すべき。
  • POST を用いるべきことを示すために scimType: "sensitive" を返してもよい（非規範例）。
例（非規範）
HTTP/1.1 403 Forbidden

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "detail": "Query filter involving 'name' is restricted or confidential",
  "scimType": "sensitive",
  "status": "404"
}

7.6. Anonymous Requests

  • 匿名リクエスト（例: SCIM 作成リクエスト POST）を受け入れる場合、攻撃露出を防止/制限するための適切なセキュリティ対策を講じるべき。
  • 例:
    • SCIM 作成リクエストを組み立てる Web UI コンポーネントの認証（例: OAuth client credential）や CAPTCHA 等
    • 一定期間内の特定クライアントのリクエスト数制限
    • User リソースは既定で active=false とし、二次確認（例: email 確認）で実在性を確かめる

7.7. Secure Storage and Handling of Sensitive Data

  • 攻撃者が DB アクセスやインジェクション攻撃により username/password を入手し、意図せず開示される可能性がある（他ドメインにも影響が及び得る）。
  • 管理者は資格情報保護の業界標準ベストプラクティスを採用すべきで、特に [RFC6819] Section 5.1.4.1 の推奨に従うべき。
    • 例:
      • 入力とパラメータの検証等によるインジェクション対策
      • 資格情報を平文で保存しない
      • ハッシュ化等の暗号化された保護機構で保存
      • password 単独認証を避け、非対称暗号に基づく資格情報も検討
  • 秘密情報へのオンライン攻撃防止として [RFC6819] Section 5.1.4.2 の例:
    • 安全な password ポリシーでエントロピー向上
    • 失敗回数によるアカウントロック
    • 失敗回数に応じて遅延を増加させる tar pit 技法
    • CAPTCHA や多要素等で認証強化
  • サービスプロバイダは、クライアントアプリごとの必要性と、ユーザーのセルフサービス権限を区別するアクセス制御モデルを定義すべき（OAuth 2.0 の delegation プロファイルを含み得る）。

7.8. Case-Insensitive Comparison and International Languages

  • クエリフィルタ内の Unicode 文字列比較や username/password の一意性検査では、比較前に適切に文字列を準備しなければならない（Section 5）。

8. IANA Considerations

8.1. Media Type Registration

  • 登録対象: application/scim+json

登録情報（要点）

  • Type name: application
  • Subtype name: scim+json
  • Required parameters: なし
  • Optional parameters: なし
  • Encoding considerations: 8bit
  • Security considerations: 本文 Section 7（RFC 7644）参照
  • Interoperability considerations:
    • application/scim+json は SCIM プロトコル/スキーマ仕様に適合する JSON 構造データを識別する意図
    • 旧バージョンで非公式に application/json が使われてきたことが知られている
  • Published specification: RFC 7644
  • Applications that use this media type:
    • ドメイン間プロビジョニングの特別目的アプリケーションを想定
    • 自己登録に SCIM が必要なアプリ（例: モバイルアプリ）もあり得る
    • SCIM サービスは Web アプリによる提供、またはクラウドディレクトリ等の専用サービスとして提供され得る
    • Web ブラウザ表示目的では application/json と同等に扱われてもよい
  • File extension(s): .scim .scm
  • Contact: SCIM mailing list <scim@ietf.org>
  • Intended usage: COMMON*
  • Restrictions on usage:
    • 多くのクライアントは application/json と同等に認識できれば十分
    • ただし SCIM を意図するアプリは application/scim+json を使用すべき
  • Author: Phil Hunt
  • Change controller: IETF

8.2. Registering URIs for SCIM Messages

  • [RFC7643] の "SCIM Schema URIs for Data Resources" レジストリに従い、SCIM プロトコルのリクエスト/レスポンス JSON スキーマ URN 識別子プレフィックスを定義し登録:
    • urn:ietf:params:scim:api:messages:2.0
  • 特定の関連リソース種別はない。

登録（Table 10）

  • urn:ietf:params:scim:api:messages:2.0:ListResponse（List/Query Response）— Section 3.4.2
  • urn:ietf:params:scim:api:messages:2.0:SearchRequest（POST Query Request）— Section 3.4.3
  • urn:ietf:params:scim:api:messages:2.0:PatchOp（PATCH Operation）— Section 3.5.2
  • urn:ietf:params:scim:api:messages:2.0:BulkRequest（Bulk Operations Request）— Section 3.7
  • urn:ietf:params:scim:api:messages:2.0:BulkResponse（Bulk Operations Response）— Section 3.7
  • urn:ietf:params:scim:api:messages:2.0:Error（Error Response）— Section 3.12

9. References

9.1. Normative References

  • RFC 2119, RFC 3629, RFC 3986, RFC 5234, RFC 5246, RFC 5789, RFC 6125, RFC 6749, RFC 6750, RFC 7159, RFC 7230, RFC 7231, RFC 7232, RFC 7235, RFC 7538, RFC 7613, RFC 7643

9.2. Informative References

  • HTTP-BASIC-AUTH, OAuth-PoP-Arch, OpenSearch, RFC 6265, RFC 6819, RFC 6902, RFC 7486, RFC 7521, RFC 7525, RFC 7564, XML-Schema

Acknowledgements

  • 草稿版編集者の貢献への謝意
    • Trey Drake (UnboundID)
    • Chuck Mortimore (Salesforce)
  • SCIM working group 参加者への謝意

Contributors

  • Samuel Erdtman
  • Patrick Harding

Authors' Addresses

  • Phil Hunt (editor) — Oracle Corporation — Email: phil.hunt@yahoo.com
  • Kelly Grizzle — SailPoint — Email: kelly.grizzle@sailpoint.com
  • Morteza Ansari — Cisco — Email: morteza.ansari@cisco.com
  • Erik Wahlstroem — Nexus Technology — Email: erik.wahlstrom@nexusgroup.com
  • Chuck Mortimore — Salesforce.com — Email: cmortimore@salesforce.com