SCIM 調査
mori5321SCIM とは?
System for Cross-domain Identity Management の 略
複数のドメイン間でユーザーデータを安全に管理し、通信するためのアプリケーションレベルのプロトコルセットです。SCIM クライアントは CRUD (作成、置換、更新、削除)操作を管理し、クエリやフィルターを適用し、Organization内でユーザーグループを作成するために統合できます。
SCIMはユーザーのライフサイクルを自動化し、プラットフォーム間でユーザーアカウントを維持することができます。
mori5321RFC-7643: System for Cross-domain Identity Management: Core Schema
RFC-7644: System for Cross-domain Identity Management: Protocol
mori5321Why SCIM?
要は
- 大企業ほど入退社時の処理が多くて IT部門はしんどい。これを自動にしよう。
- 退社時のアカウント剥奪処理を自動化できれば、セキュリティリスクも低減できる。
企業が成長を遂げ、革新を打ち出し、従業員の入れ替わりを重ねるにつれ、ユーザーアカウントの数は急激に増加します。従業員は、顧客関係管理からチームでのコラボレーションまであらゆる業務にユーザーアカウントを使用します。ここで、ユーザーの追加や削除、アクセス権の変更、別の種類のアカウントの追加といったリクエストはすべて、IT 部門の貴重な時間を奪うことになるのです。
SCIM では、Oktaのようなツールを使って直接ユーザーアイデンティティを作成したり、人事ソフトウェアや Active Directory などの外部システムからインポートしたりできます。SCIM は標準規格であるため、ユーザーデータは一貫した方法で保存され、さまざまなアプリケーション間でやり取りできます。これにより、IT 部門ではプロセスのプロビジョニングとプロビジョニング解除を自動化できると同時に、単一のシステムでアクセス権やグループの管理ができるようになります。データは自動転送されるため、エラーのリスクも少なくなります。
IT 部門は、企業のディレクトリをさまざまな外部ツールやアプリケーションに接続するカスタム統合を開発して定期的に更新する必要がなくなります。IT 部門以外の従業員は、シングルサインオン（SSO）を利用することで各自のワークフローを簡素化できるとともに、パスワードのリセットで IT 部門に作業してもらう回数を最大で 50% も減らすことができるのです。
同時に、SCIM を採用することで、企業が直面する多くのセキュリティリスクも低減できます。従業員がサインオンにそれぞれ別のアカウントを使う必要がなくなると、企業はセキュリティポリシーコンプライアンスを確実に遵守できます。また、複数のツールやアプリケーションで同じパスワードを使い回すことに伴うリスクも低減されます。チームが新たなワークフローを開発したり新しいアプリケーションを採用したりしても、企業はアカウントの追跡ができなくなるリスクを負うことなく、こうした変更に対処できるのです。
mori5321SCIMの仕組み
- REST 及び JSON ベースのプロトコル
- クライアント: Oktaのような IdP
- サービスプロバイダー(SP): Box や Slack などの SaaS アプリケーション
IdP で 作成、更新、削除といったアイデンティティの変更が行われると、これらの変更はSCIMプロトコルに従って自動的にSPに同期される。
また逆方向のチェックも行われており、SP側の情報を取得して IdP側と照らし合わせて不正な値が残っていないかもチェックしている。
- 退職したはずの 社員のアカウントがSP側に残っていないか?
- 本来与えられていないはずの高い権限が SP側で付与されていないか?
mori5321RFC-7643を読む
RFC-7643 -- Abstract
The System for Cross-domain Identity Management (SCIM) specifications
are designed to make identity management in cloud-based applications
and services easier
SCIMはcloud-based applications の identity management をより簡単にするためにつくられた。
Its intent is to
reduce the cost and complexity of user management operations by
providing a common user schema and extension model as well as binding
documents to provide patterns for exchanging this schema using HTTP.
This document provides a platform-neutral schema and extension model
for representing users and groups and other resource types in JSON
format. This schema is intended for exchange and use with cloud
service providers.
同期をするための userの標準schema と そのextension modelを定義し、複雑さを排除する。
user 以外にも groups や 他の resource types も JSON schema として表現される。
mori5321太字が優先的に読んだ方がよさそうなところ
RFC-7643 -- Table of Contents
Table of Contents
1. Introduction and Overview .......................................3
1.1. Requirements Notation and Conventions ......................4
1.2. Definitions ................................................5
2. SCIM Schema .....................................................6
2.1. Attributes .................................................7
2.2. Attribute Characteristics ..................................8
2.3. Attribute Data Types .......................................8
2.3.1. String ..............................................9
2.3.2. Boolean .............................................9
2.3.3. Decimal ............................................10
2.3.4. Integer ............................................10
2.3.5. DateTime ...........................................10
2.3.6. Binary .............................................10
2.3.7. Reference ..........................................10
2.3.8. Complex ............................................11
2.4. Multi-Valued Attributes ...................................11
2.5. Unassigned and Null Values ................................13
** 3. SCIM Resources .................................................13
3.1. Common Attributes .........................................16
3.2. Defining New Resource Types ...............................18
3.3. Attribute Extensions to Resources .........................18**
4. SCIM Core Resources and Extensions .............................19
4.1. "User" Resource Schema ....................................19
4.1.1. Singular Attributes ................................19
4.1.2. Multi-Valued Attributes ............................23
4.2. "Group" Resource Schema ...................................25
4.3. Enterprise User Schema Extension ..........................26
5. Service Provider Configuration Schema ..........................27
6. ResourceType Schema ............................................29
7. Schema Definition ..............................................30
8. JSON Representation ............................................34
8.1. Minimal User Representation ...............................34
8.2. Full User Representation ..................................35
8.3. Enterprise User Extension Representation ..................39
8.4. Group Representation ......................................43
8.5. Service Provider Configuration Representation .............44
8.6. Resource Type Representation ..............................46
8.7. Schema Representation .....................................47
8.7.1. Resource Schema Representation .....................47
8.7.2. Service Provider Schema Representation .............74
9. Security Considerations ........................................92
9.1. Protocol ..................................................92
9.2. Passwords and Other Sensitive Security Data ...............92
9.3. Privacy ...................................................92
10. IANA Considerations ...........................................94
10.1. Registration of SCIM URN Sub-namespace and SCIM
Registry .................................................94
10.2. URN Sub-namespace for SCIM ...............................94
10.2.1. Specification Template ............................95
10.3. Registering SCIM Schemas .................................97
10.3.1. Registration Procedure ............................97
10.3.2. Schema Registration Template ......................98
10.4. Initial SCIM Schema Registry .............................99
11. References ...................................................100
11.1. Normative References ....................................100
11.2. Informative References ..................................101
Acknowledgements .................................................103
Authors' Addresses ...............................................104
mori5321RFC-7643 -- 1. Introduction and Overview
user informatin を交換する標準プロトコルはこれまでいくつかあったが、どれも複雑で実装が難しい。
そのため各社がそれぞれの非標準protocolを開発してきた。これにより、複数のクラウドプロバイダーから製品やサービスを導入する組織は、重複した連携開発を行わなければならなくなるため、コストと複雑性の両方が増大している。
SCIMはこの問題を 以下のものをつかって解決する
-
実装が簡易な仕様のセット
- 標準のuser schema を提供する
- extention model も 提供する
- SCIM protocol document
- このschema をどう HTTP-based protocol で 交換するか
SCIMは
- application-level の protocol である
- identity data をschema を通じて管理する
- 以下をsupportする
- create
- modification
- retrieval
- discovery of core identity resources (e.g. Users, Groups)
- HTTP methods の subset を使う
- GET: retrieval
- POST: create
- PUT: attribute replacement
- PATCH: partial update of attributes
- DELETE: removing resources
SCIM Protocol と Core Schema の 仕様は point-to-point のシナリオを対象としているが、実装者や導入者はマルチホップやマルチパーティのシナリオも考慮すべきである。
マルチホップ: A->B->C
マルチパーティ: B -> A <- C
このような複雑な構成を組む場合には、誰がどの時点のデータに責任を持つのか SLAなどの合意書で明確にしておく必要がある。(Section 9.3 にて詳しく述べる)
mori5321RFC-7643 -- 1.2 Definitions
Service Provider
SCIM protocol を用いて identity information を提供する HTTP web application
Client
Service Provider の identity data を管理するためにSCIM Procol を用いるwebsite あるいは application。client が SCIM HTTP request を target となるService Provider に対して開始する。
Provisioning Domain
??? WIP
Resource Type
サービスプロバイダーによって管理されるリソースの種類。リソースタイプは、リソース名、エンドポイントURL、スキーマ、およびリソースがどこで管理され、どのように構成されているかを示すその他のメタデータを定義します。例：「User」や「Group」。
Resource
サービスプロバイダーによって管理される、1つ以上の属性（attribute）を持つ実体（アーティファクト）のこと。例：「User」や「Group」。
Endpoint
サービスプロバイダーのベースURI (SEE: Section 1.3)からの相対パスとして定義される、SCIMリソースに対するSCIM操作を実行できるパスのこと。
例
Schema
リソース全体またはその一部の内容を記述する、属性定義の集合。
例：urn:ietf:params:scim:schemas:core:2.0:User。
属性定義は、属性の名前や、型（例：文字列、バイナリ）、カーディナリティ（単数、複数、複合）、可変性、返却可能性といったメタデータを指定します。
Singular Attribute
0個または1個の値を持つリソース属性。例：「displayName」。
Multi-valued Attrubtue
個以上の値を持つリソース属性。例：「emails」。
Simple Attribute
値がプリミティブ型（例：「String」）である単数属性または複数値属性。単純属性は、下位属性（sub-attribute）を含んではいけません (MUST NOT)。
Complex Attribute
値が1つ以上の単純属性の組み合わせで構成される、単数属性または複数値属性。例えば、「addresses」属性は、「streetAddress」、「locality」、「postalCode」、「country」といった下位属性を持ちます。
Sub-Attribute
複合属性に含まれる単純属性のこと
mori5321RFC-7643 -- 2. SCIM Schema
- ユーザーとグループを表すための 最小限のコアスキーマを提供する。
- 各Attributeは異なる type, mutability, cardinarility, returnability を持てる
- muitability: 登録後に変更できるか
- readonly
- readWrite
- Writeonly
- immutable
- cadinality: いくつもてるか
- Singular
- Multi-valued
- returnability: APIで情報を問い合せたときに、その項目を結果に含めるか
- id: 常に返す(always)
- displayName: 通常は返す(default)
- password: 返さない(never)
- groups: 要求された場合のみ返す(request)
- muitability: 登録後に変更できるか
- validationは受信者によって行われる
2.1 Attributes
BNF (ABNF)
ATTRNAME = ALPHA *(namechar)
nameChar = "$" / "-" / "_" / DIGIT / ALPHA
- 1文字目がアルファベットである必要がある
- case insensitive
- ASCIIで構成される
- 記号は $, -, _ のみ
2.2 Attribute Characteristics
すべてのAttributeは service provider がどう handling するかを示す、一連の「特性(Attribute Characteristics)」を持つ。
例をあげるとこんなやつら。
- type
- uniqueness
- required
- canonicalValues
- caseExact
- mutability
- returned
詳細は Section 7 にて説明されるので、ここでは割愛。
2.3 Attribute Data Types
はい、承知いたしました。
| SCIM Data Type | SCIM Schema "type" | JSON Type |
|---|---|---|
| String | "string" | String per Section 7 of [RFC7159] |
| Boolean | "boolean" | Value per Section 3 of [RFC7159] |
| Decimal | "decimal" | Number per Section 6 of [RFC7159] |
| Integer | "integer" | Number per Section 6 of [RFC7159] |
| DateTime | "dateTime" | String per Section 7 of [RFC7159] |
| Binary | "binary" | Binary value base64 encoded per Section 4 of [RFC4648], or with URL and filename safe alphabet URL per Section 5 of [RFC4648] that is passed as a JSON string per Section 7 of [RFC7159] |
| Reference | "reference" | String per Section 7 of [RFC7159] |
| Complex | "complex" | Object per Section 4 of [RFC7159] |
- String => 割愛
- Bool => 割愛
- Decimal => 少なくとも1桁の実数
- Integer => 整数
- DateTime => 日付時刻
- Binary => 任意のバイナリデータ (base64 encode されている必要がある)
- Reference => リソースのURI (e.g. SCIMリソース、画像などの外部リンク)
- Complex => 複数のsub attributeをまとめた グループ (例: 住所)
- complex は next してはいけない
2.4 Multi-Valued Attributes
リストが扱えるよぐらいの理解で大丈夫そう
2.5 Unassigned and Null Values
mori53213. SCIM Resource
SCIMリソースは次のcomponentを持つJSONオブジェクトです。
-
core attribute schema
-
any attribute extention schema
-
同一typeのobjectが存在するエンドポイントを定義する resourceType
-
"Schemas" attribute
- 必須属性
- JSONのstructureに存在するattributeの形式を規定するschemaに対する 名前空間
- たぶん schema: "User" みたいなことだと思う
- 複数のschemas を指定できる
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
- Common Attributes
- すべてのSCIMリソースに共通して現れる、IDやメタデータなど共通のattribute
- e.g. id, schemas, meta
- Core Attributes
- 「ユーザー」や「グループ」といった特定リソースタイプ。標準的に定義された Attributes
- e.g. User の場合
- userName
- name
- emails
- displayName
- active
- Extended Attributes
- 標準仕様にはない、独自に追加可能なカスタム Attributes
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"id": "2819c223-7f76-453a-413861904646",
"externalId": "701984",
"userName": "bjensen@example.com",
"name": {
"formatted": "Ms. Barbara J Jensen, III",
"familyName": "Jensen",
"givenName": "Barbara",
"middleName": "Jane",
"honorificPrefix": "Ms.",
"honorificSuffix": "III"
},
...
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "701984",
"costCenter": "4130",
},
"meta": {
"resourceType": "User",
"created": "2010-01-23T04:56:22Z",
"lastModified": "2011-05-13T04:42:34Z",
"version": "W\/\"3694e05e9dff591\"",
"location": "https://example.com/v2/Users/2819c223-7f76-453a-413861904646"
}
}
RFC-7643; 4. SCIM Core Resource and Extensions
4.1 "User Resource Schema"
schemaURI: "urn:ietf:params:scim:schemas:core:2.0:User"
Single
- userName: service provider における userを表す 一意の識別子
- name: 氏名
- displayName: 表示名
- nickname: ニックな０無
- profileUrl:
- title: 約束
- userype: 組織とユーザーの関係 (Employee, Intern, External など)
- locale
- langauage
- timezone
- active
- pasword
- etc ...
Multi-valued
- emails
- phoneNumbers
- ims (インスタントメッセージングアドレス)
- photos (ユーザー画像)
- addresses
- groups: ユーザーが属するグループのリスト- これは認可が絡んでやや重要そう
- entitlements: 資格とか
- roles: ユーザーが誰であるか (学生とか教員とか)
- x509Certificates: 証明書のリスト
4.2 "Group Resource Schema"
schemaURI: "urn:ietf:params:scim:schemas:core:2.0:Group"
- displayName
- members: メンバーのリスト
- values (multi values)
- id: SCIMリソースのID
- $ref: SCIMリソースのURI
- values (multi values)
4.3 "Enterprise user Schema Extention"
schemaURI: "urn:ietf:params:scim:schemas:core:2.0:Group"
組織名とか部門名とか managerが誰かとか示すためのいろいろがある。
mori5321RFC-7643; 5. Service Provider Configuration Schema
サービスプロバイダーはクライアントに追加の実装の詳細を提供することができる。
一例
- changePassword: パスワード変更に関連する構成オプションを指定する。complex type
- maxPayloadSize: 最大ペイロードサイズをバイト単位で指定する
- type: 認証スキーム (oauth, oauth2, httpbasic, oathbearertoken, httpdigest)
- name: 認証スキーム名 (HTTP Basic)
mori5321RFC-7643; 8. JSON Representation
JSONでのschema定義の実例
ここのページ見るとだいたいschemaの雰囲気わかる。
詳細は当Scrapでは割愛
mori5321余談: IdP <-> SP の Integration のイメージがわかりやすいやつ
- API Token 発行して認証するもよう
- Okta だと専用のUIがあってポチポチしたらmappingできるっぽい
mori5321RFC-7644: SCIM Protool
ここからは Protocol について 言及した RFC 7644について
mori5321RFC-7644: 2. Authentication and Authorization
SCIMプロトコルは HTTPに基づいており、SCIM固有の認証のためのschemeを定義しない。
TLS や 標準のHTTP AuthN/AuthZ schema RFC7235 に依存している。
たとえば特に次の方法が使える
- TLS Client Authentication
- HOBA Authentication (HTTP Origin-Bound Authentication)
- キーペアによる認証
- Bearer Tokens
- このトークンを持ってるだけでアクセス権限が証明される
- PoP Tokens (a proof-of-posession token)
- Bearer Token のセキュリティを強化したもので、持っていることに加えて、そのトークンを正当に所有していることを暗号学的に証明する
- Cookies
- Basic Authentication
SCMサービスプロバイダーは "WWW-Authenticate" ヘッダーを介して、サポートされているHTTP認証スキームを示す必要がある。
2.1 Use of Tokens as Authorization
OAuth によって発行された Bearer Token や PoP Tokenを用いる場合、実装者は Grant Type や Scope や Security Subject を考慮する必要がある。
2.2 Anonymous Request
SCIM 作成要求など 一部の処理は、認証なしの匿名リクエストを許容される場合がある。
mori5321RFC-7644: 3. SCIM Protocol
プロトコルの基本
-
HTTP Based
-
JSON の payload を利用する
-
Content-Type: application/scim+json
-
/Schemas エンドポイントにリクエリを実行することで Service Provider の schema 定義が取得できる
-
SCIM Client は どの属性が「読み取り専用であるか」を検出する必要はない。
- 例: PUT の 場合
- Service Provider 側が 属性の mutabilityを見て判断する。
- 例) readOnly なら更新は無視。readWriteなら更新を行う
- 例: PUT の 場合
クエリエンドポイントについて
Filter & Sort & Pagination の実装サポートしないといけないもの多くてだいぶめんどくさそう...。
Bulk Request も必須? => Opional っぽい。
循環参照はサービス・プロバイダ側がハンドリングする。409 Conflicted を返す。
bulkId とは?
- Bulk Request では「ユーザーを作成して、グループを作成して、グループに追加する」を一括でやることもできる
- グループに追加するための GroupIDをbulk request では参照できない
- bulkID という仮のIDを指定することで、その仮IDを正規のuserIDに置き換える
mori5321実装例
Safie
-
SSO(シングルサインオン)機能を実装するための取り決めとしてSAMLを使用する
-
ディレクトリ連携機能を実装するための取り決めとしてSCIMを使用する
-
Azure Active Directory で debug してたっぽい
Cybouz (この記事が非常に取っ掛かりによかった！！！)
プロトコルとはいえ連携可能サービスのターゲットを決めているっぽい
- Microsoft Entra ID
- Okta
- OneLogin
- Google Workspace
- Ping Identity
各IdPから自動試験ツールが提供されているらしい
mori5321個人的まとめ
SCIM とは
- SCIMとはユーザーディレクトリ連携のためのプロトコルである
- IdP のユーザー情報を Service Provider に 同期する
- Service Provider 側に 不正な情報がないか IdP側と照合して修正する
- SCIM は HTTP Based な プロトコルである
- SCIM は Schema を定義する
- Core Schema: User/Group など
- SCIM は Schema の拡張方法を定義する
- SCIM は Endpoint の仕様を定義する
- 基本的なCRUD
なんのためのもの?
要は入社時のアカウント作成、退職時のアカウント削除を楽にしたい。
もれなくやることでセキュリティを担保したい。
IdP とは
Identity Provider
ユーザーディレクトリを持つ代表的なやつ
- Microsoft Entra ID(Azure Active Directory?)
- Google Workspace
- Okta
- OneLogin
- Ping Identity
User Directory とは
ユーザーアカウント情報を一元的に保存管理しているシステムのこと。
IdPの中のユーザーデータベースがその一例。
Service Provider とは
SCIMにおいて、IdP から ユーザー情報を連携される側の SaaS
疑問点
Q. Attributeのマッピングはどこで行う?
IdP(User Directory) => SCIM Protcol => Service Provider
Q. IdPのattribtue.A と SCIMのattribute.X が対応することを誰がどう設定する?
A. 主要なIdP は Mapping のための 機能・UIを提供している。ユーザーはポチポチするだけ。
プロビジョニング機能 や 属性マッピング機能と呼ばれていることが多い?
SEE: https://support.knowbe4.com/hc/ja/articles/4402065050771-Okta向けのSCIMの設定
Q. Service Provider が 実装しないといけないものは?
- IdP -> Service Provider の認証
- 選択肢はいくつかある
- OAuth2.0
- Secret Token
- Basic Authentication
- ※これもIdPによってサポートしている認証方法が異なる気がする...。
- 選択肢はいくつかある
- 認証用シークレットトークンの発行機能
- Schema の定義
- Service Provider に合わせて core schema や extented schema をどう扱うか決める
- プロトコルによって定められたエンドポイントの実装 (5~10個程度)
- optional なエンドポイントもある。プロトコルとはいうものの IdPによって必須なものが違うらしい。
- ほとんどが基本的なCRUDエンドポイントだが、結構仕様がしっかりしており実装はやや重め。
- 例えば READ には filter/sort/pagination が求められており、仕様も細かく決まっている
- たぶん optionalだが bulk の操作を可能にするエンドポイントも要求される
Q. 実装が重そうなのは? (肌感)
- IdP -> Service Provider の認証が当然気を使うので大変
- filtering & sort も仕様が多くて重そう (いくつかはoptionalっぽい?)
- bulk API が重そう (optional っぽい?)
その他備考
- 多くのIdP が自動テストツールを提供してくれている模様
- プロトコルがあるとはいえ、どのIdPをターゲットにするか定めておいた方がよい (微妙に要求してくるものが違うため)