-
Notifications
You must be signed in to change notification settings - Fork 0
MS_SCIM
-
TOP > インフラストラクチャ > 認証基盤 > クレームベース認証
- SCIM
- SAML / WS-FED
- STS系ミドルウェア
2011 年、SCIM 1.0 発表。
- ID 情報をプロビジョニングやデプロビジョニングで CRUD 操作する RESTful API 仕様
- 認証・認可に関する仕様は定義されていないが、
推奨は OAuth 2.0 ベアラートークン。
補足: SCIM の狙いを一言でいうと「アカウントの作成・更新・削除を SaaS 間で自動化する」ことである。 SAML や OpenID Connectが 「**認証(ログイン)**の連携」を担うのに対し、 SCIM は「**アカウント(ID そのもの)**の連携」を担う。
目的 仕様 ログインを連携する SAML / WS-Federation / OpenID Connect アカウントを配る・消す SCIM 両者は補完関係にある。SSO だけを入れると、 退職者のアカウントが SaaS 側に残り続ける (デプロビジョニング漏れ)という典型的な問題が起きる。
- SPML のときには BMC や Sun などのプロビジョニング製品ベンダが中心となっていたが、
- SCIM では、Google や Salesforce.com、Cisco、VMware といった
有力な CSP が積極的に仕様策定の議論に関与
| # | 特徴 | SPML と比較して |
|---|---|---|
| 1 | ユーザー管理の標準化 | 相互運用性の向上 |
| 2 | WebAPI (RESTful) | 相互運用性の向上 |
| 3 | CRUD(Create, Read, Update, Delete)に特化 | 複雑性の減少 |
| 4 | シンプルで拡張しやすいユーザ・スキーマ | オプションのユーザースキーマ対応 |
| # | 公開日 | 公開 |
|---|---|---|
| 1 | 2011 年 12 月 | SCIM 1.0 発表 |
| 2 | 2012 年 7 月 | SCIM 1.1 発表 |
| 3 | 2015 年 9 月 | SCIM 2.0 RFC 化(XML に関する仕様が削除) |
補足: SCIM 1.x と 2.0 には互換性が無い。 名称も 1.x では "Simple Cloud Identity Management" だったものが、 2.0 で "System for Cross-domain Identity Management" に変わっている。 現在の実装は基本的に 2.0 である。
| # | 用語 | 意味 |
|---|---|---|
| 1 | リソース | 管理対象のオブジェクトのこと |
| 2 | 属性 | オブジェクトが持つ項目 |
コア スキーマ(RFC 7643)では User と Group が定義されている。
スキーマは URN で識別され、拡張スキーマを追加できる。
urn:ietf:params:scim:schemas:core:2.0:User
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
補足: 相互運用でつまずくのは、 ほぼ属性のマッピングである。 どの属性を一意キーにするか(
userName/externalId/id)は 実装ごとに解釈が分かれる。
id— サービス プロバイダ側が採番する不変の識別子externalId— クライアント(IdP)側が付ける識別子userName— ログイン名。変更されうるのでキーには向かない氏名の変更やメール アドレスの変更に耐えるよう、
externalIdに不変の値を入れる設計にすること。
| # | HTTP Method | SCIM での使用について |
|---|---|---|
| 1 | GET | 参照(JSON) |
| 2 | POST | 追加(や、一括操作、検索実行) |
| 3 | PUT | 更新 |
| 4 | PATCH | 部分変更 |
| 5 | DELETE | 削除 |
ベース URL +エンドポイント URL に、HTTP メソッドを使用して動作を定義。
| # | リソース | エンドポイント | メソッド | 説明 |
|---|---|---|---|---|
| 1 | User | /Users |
GET / POST / PUT / PATCH / DELETE | ユーザーの取得・追加・更新・部分更新・削除 |
| 2 | Group | /Groups |
GET / POST / PUT / PATCH / DELETE | グループの取得・追加・更新・部分更新・削除 |
| 3 | Self | /Me |
GET / POST / PUT / PATCH / DELETE | 認証された自分のユーザーアカウントに対する操作 |
| 4 | Service provider configuration | /ServiceProviderConfig |
GET | サポートする特定の SCIM プロトコル機能を取得 |
| 5 | Resource type | /ResourceTypes |
GET | サポートしているリソースタイプを取得 |
| 6 | Schemas | /Schemas |
GET | サポートするスキーマの取得 |
| 7 | Bulk | /Bulk |
POST | 複数のリソースの一括更新 |
| 8 | Search | [prefix]/.search |
POST | 特定のリソースタイプまたはすべてのリソースタイプへの検索 |
移行メモ(正誤): 元ページの表では Group のエンドポイントが
/Group、 サービス プロバイダ構成が/ServiceProviderと記載されていたが、 RFC 7644 の定義は/Groups(複数形) および/ServiceProviderConfigである。 また、リソース番号の 2 が重複していたため通し番号を振り直した。
補足:
PUTはリソース全体の置き換えなので、 送らなかった属性が消える。 実運用ではPATCHを使うのが基本である (REST の PUT / PATCH の使い分けと同じ話)。
補足(最新化): Microsoft Entra ID(旧 Azure AD)は SCIM 2.0 のクライアント(プロビジョニング元)として動作する。 エンタープライズ アプリケーションの 「プロビジョニング」でテナント URL とシークレット トークンを設定すると、 ユーザ・グループが自動的に同期される。
- 同期は約 40 分間隔の増分処理で、リアルタイムではない
- 割り当てを外すと無効化または削除が飛ぶ(デプロビジョニング)
- 逆方向(オンプレ AD → Entra ID)は SCIM ではなく Microsoft Entra Connect が担当する
- ADPr(Active Digital Profile)
- XRPM(eXtensible Resource Provisioning Management)
- ITML(Information Technology Markup Language)
- WS-Provisioning
- SPML(Service Provisioning Markup Language)
OASIS より、2003 年に初版が、2006 年に第 2 版が登場。
-
サービス・プロビジョニング
- 特徴: XMLベースのオープン標準プロトコル
- 目的: 管理(設定、変更、削除)が必要な工程の自動化
- 対象: ユーザ、システムアクセス、関連するデータなど
-
流行らなかった理由
- 仕様が汎用的であるがゆえに複雑
- SOAP
- CRUD 以上の操作を多数定義
- DSML 由来のためスキーマ拡張が面倒
- 相互運用性の欠如
- オプションのスキーマ欠如
- SPML に対応するサービスが少ない(プロビジョニング製品ベンダが中心)
- 仕様が汎用的であるがゆえに複雑
移行メモ(正誤): 元ページは 「2003 年に第 2 版が、2006 年に第 2 版が登場」としていたが、 SPML 1.0 が 2003 年、SPML 2.0 が 2006 年であり、 前者は初版の誤記である。
- クレームベース認証
- 認証基盤
- RFC 7642 - SCIM: Definitions, Overview, Concepts, and Requirements
- RFC 7643 - SCIM: Core Schema
- RFC 7644 - SCIM: Protocol
- SCIMを知らない人向けSCIMの超基礎 - Qiita
- SPML - Wikipedia
Tags: IT国際標準, 認証基盤, クレームベース認証
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。