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

## 前書き 
これは[DMM.com #2 Advent Calendar 2017 - Qiita](https://qiita.com/advent-calendar/2017/dmm2) 17日目の記事です
昨日は @shinderuman さんの
[開発環境の構築をモブプログラミングを用いてやってみた話](https://qiita.com/shinderuman@github/items/bcb1ce5b13efd9c93745)でした

カレンダーのURLはこちら
- [DMM.com #1 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/dmm) 
- [DMM.com #2 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/dmm2)

本記事は、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を実装しましょう(小並感)