Edited at

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


前書き

これはDMM.com #2 Advent Calendar 2017 - Qiita 17日目の記事です

昨日は @shinderuman さんの

開発環境の構築をモブプログラミングを用いてやってみた話でした

カレンダーのURLはこちら

- DMM.com #1 Advent Calendar 2017

- DMM.com #2 Advent Calendar 2017

本記事は、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つ


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
/ServiceProvider
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を実装しましょう(小並感)