SCIMを知らない人向けSCIMの超基礎 #scim

前書き

これはDMM.com #2 Advent Calendar 2017 - Qiita 17日目の記事です
昨日は @shinderuman さんの
開発環境の構築をモブプログラミングを用いてやってみた話でした

カレンダーのURLはこちら

本記事は、SCIM初心者による、SCIM初心者に向けた記事になります

tl;dr

SCIMとはプロビジョニングやデプロビジョニング用のID情報を
RESTfulなAPIでCRUDで操作する時の標準プロトコル

対象の読者

SCIMについて興味があり、SCIM初心者の方
ID情報のプロビジョニング・デプロビジョニングに興味がある方
10分ほど時間が空り、丁度よい時間つぶしの方法が無い方

背景

多くの組織では、ユーザーを認証してSSO(シングルサインオン)を提供しており、
ユーザーが何らかのSSOシステムを利用する場合、システムを利用するためのアカウントと
それに適切な権限がされている必要がありますよね。

ではどのように複数のシステム間をまたがって行われる
アイデンティティ・プロビジョニング(ユーザ・アカウントとアクセス権限の継続的な管理)
を行うのでしょうか？

システム間のインタフェースとして各サービス独自のプロトコルやフォーマット?
ディレクトリ・システムであればLDAP、データベースであれば各製品固有の通信プロトコル?
もしかしたら…CSVでアカウントの情報を管理している?

Identity管理の進歩

勿論、アイデンティティ管理業界も日々進化しており
プロビジョニングに関連する仕様も過去に沢山登場してます。

ADPr（Active Digital Profile）
XRPM（eXtensible Resource Provisioning Management）
ITML（Information Technology Markup Language）
WS-Provisioning
SPML

SPMLはだめなのか？

SPMLは2003年、OASISよりSPNLの最初のバージョンが承認、2006年に第2版が登場！
~~あのOASISですよ！　SAMLの仕様も決めたOASISですよ！~~
~~これで勝つる!、流行るに違いない！！~~
~~え、SAML以外は…ですって？~~

何故流行らなかったのか…

複雑さ及び、相互運用性の欠如
オプションのスーザースキーマの欠如
アプリケーションベンダーによるサポート不足

そんな中、2011年、SCIM1.0発表！

SCIM（System for Cross-Domains Identity Management）とは

Web(ABFAB)及びSAML2のようなSSOのためのアプリケーションの橋渡しのような
いくつかのプロトコルの実装とは異なり、認証(JITプロビジョニング)とは別のコンテキストで
リソースプロビジョニングとデプロビジョニングを提供するもの

※ RFC7642のセクション1 (3ページ目)参考

SCIMの特徴

特徴	SPMLと比較して
ユーザー管理の標準化	相互運用性の向上！
WebAPI (RESTful)	相互運用性の向上！
CRUDに特化	複雑性の減少！
拡張できるスキーマ	オプションのユーザースキーマ対応！

SCIMの歴史

公開日	公開
2011年 12月	SCIM1.0発表
2012年 7月	SCIM1.1発表
2015年 9月	SCIM2.0RFC化 (XMLに関する仕様が削除)

この標準は当初Simple Cloud Identity Managementと呼ばれていましたが、IETFが
それを採用したときにSCIM（System for Cross-Domains Identity Management）に正式に変更されました。

RFCの対象になったのは以下の3つ

RFC7642(http://www.rfc-editor.org/rfc/rfc7642.txt)
定義、概要、概念、および要件やユースケースについて
RFC7643(http://www.rfc-editor.org/rfc/rfc7643.txt)
コアスキーマについて
RFC7644(http://www.rfc-editor.org/rfc/rfc7644.txt)
プロトコルについて

SCIMの関連の用語

用語	意味
リソース	管理対象のオブジェクトのこと
属性	オブジェクトが持つ項目

SCIMの標準スキーマ仕様

下位互換性のために、いくつかの既存のスキーマ定義はスキーマの一部としてリストしても良い
下記の属性特性は既存のスキーマに含まれる可能性のある古い定義より優先される。

属性名	説明
id	サービスプロバイダによって定義されたSCIMリソースの一意の識別子
externalId	プロビジョニングクライアントによって定義されたリソースの識別子
meta	リソースのメタ属性を含む、Complex型の属性

※ RFC7643のセクション3.1(15ページ目)参考

SCIMで使用されるHTTPメソッド

HTTP Method	SCIMでの使用について
GET	SCIMリソースをJSONドキュメントとして取得
POST	新しいリソースの作成。一括操作の実行や検索の実行にも使用される。
PUT	全ての属性を新しい値で置き換えによる変更。
PATCH	部分的な変更。
DELETE	指定されたリソースの削除

※ RFC7644のセクション3.2(8ページ目)参考

SCIMで使用されるHTTPのエンドポイント

全てのSCIMリソースにはURLが存在し、それらは3つの要素で構成される。
サービスプロバイダーへのすべての要求は、ベースURLから派生したURLに、HTTPメソッドを仕様して行われる

SCIMサーバーのベースURL (例)	リソースタイプ	特定のリソースの識別子
https://nakakyon.com/v2	Users	9674-7830

ベースURLにはクエリ文字列を含んではいけません

リソース	エンドポイント	HTTP動詞	説明
User	/Users	GET, POST, PUT, PATCH, DELETE	ユーザーの取得、追加、変更、削除
Group	/Groups	GET, POST, PUT, PATCH, DELETE	グループの取得、追加、変更、削除
Self	/Me	GET, POST, PUT, PATCH, DELETE	認証された自分のユーザーアカウントに対する、取得、追加、変更、削除
Service provider configuration	/ServiceProviderConfig	GET	サポートする特定のSCIMプロトコル機能を取得
Resource type	/ResourceTypes	GET	サポートしているリソースタイプを取得
Schemas	/Schemas	GET	サポートするスキーマの取得
Bulk	/Bulk	POST	複数のリソースの一括更新
Search	[prefix]/.search	POST	特定のリソースタイプのエンドポイントまたはすべてのリソースタイプへの検索

※ RFC7644のセクション3.2(9ページ目)参考

リクエストの例

   POST /Users  HTTP/1.1
   Host: nakakyon.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"
     }
   }

※ RFC7644のセクション3.3(11ページ目)参考

レスポンスの例

サービスプロバイダが新しいリソースを正常に作成すると、HTTPステータスコード201が返されるべき。
レスポンスボディは新しく作成されたリソースのサービスプロバイダの表現を含むべき。
作成されたリソースのURIは、HTTP "Location"ヘッダーとHTTP本文に属性"meta.location"を
持つJSON表現[RFC7159]を含めるべき。

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

※ RFC7644のセクション3.3(12ページ目)参考

認証・認可について

SCIMの仕様には認証・認可に関する仕様は定義されていません。
推奨はOAuth2.0 ベアラートークン。

最後に

SCIMに則ったAPIを実装しましょう(小並感)