本報告では2011年上半期のアイデンティティ管理技術に関する動向として、アイデンティティ・プロビジョニング・インタフェースの標準化を目指すSCIM（Simple Cloud Identity Management）の概要を紹介する。

　ユーザが情報システムを利用するためには、先だってそのシステムへのログインに必要なユーザ・アカウントが存在し、かつ必要なアクセス権限が設定されている必要がある。そしてユーザの立場や役割の変化（例： 企業内における社員の異動や昇進、コンシューマー向けサービスにおける普通会員から特別会員へのアップグレード）に応じ適切にアクセス権限を付与・剥奪し、さらに利用資格を喪失した際（例：退職や休職、退会、利用料未払い）には、ユーザ・アカウントの無効化や削除を行わなくてはならない。このような、ユーザ・アカウントとアクセス権限の継続的な管理を、アイデンティティ・プロビジョニングと呼ぶ。
　複数のシステム間をまたがって行われるアイデンティティ・プロビジョニング（例：人事アプリケーション・システムから社内ディレクトリ・システムへ、契約者管理データベースからWeb サイトの会員データベースへ）では、ほとんどの場合、システム間のインタフェースとして各サービス独自のプロトコルやフォーマットが利用されている。たとえばディレクトリ・システムであればLDAP、データベースであれば各製品固有の通信プロトコルであり、場合によってはCSVファイルによってアカウント情報の更新を行うことも少なくない。
　これらのサービスごとに違うインタフェースを統一するべく、過去、OASISのサービス・プロビジョニング技術委員会 [1] によって策定されたのがSPML（Service Provisioning Markup Language）[2] である。SPMLはアカウント管理に特化したものではなく、より汎用的な、XMLによってサービス・プロビジョニング情報を交換するためのフレームワークであり、2003年にバージョン1.0が、2006年に同2.0がOASISによって承認されている。
　SPMLは従前に存在した3つのプロビジョニング製品ベンダーの外部インタフェースを統一した仕様であり、これに代わる他の仕様は存在しなかったことから、この分野ではSPMLが主流になるとみられていた。しかし今日現在、SPMLの普及は進んでいない。この背景には、仕様が汎用的であるがゆえに複雑であることと、SPMLに対応する製品・サービスが少ないことが挙げられる。

(1) 概要

　SPMLは広まらなかったものの、アイデンティティ・プロビジョニング・インタフェースの標準化のニーズは消えたわけではなく、むしろ以前より高まっている。最も大きな要因は、「クラウド・サービス」の利用拡大である。
　CSP（Cloud Service Provider：クラウド・サービス事業者）の多くはユーザ管理機能を Web API 化し、ECS（Enterprise Cloud Subscriber：ユーザ企業などといった、サービスを利用する組織）に提供しているが、そのAPI仕様はCSPごとにまちまちであり、互換性がない。そのためECSが自社ID管理システムからクラウド・サービスへのプロビジョニングを行うためには、たとえばユーザの追加・削除といった単純な操作であっても、CSPごとに異なるAPIに対応しなくてはならない。
　このような状況に対し、クラウド・サービスのアイデンティティ・プロビジョニング・インタフェースの統一を目指す動きとして登場したのが SCIM（Simple Cloud Identity Management）[3] である。SCIMの特徴は下記の通り。

• RESTfulなWeb API（SPML は SOAP）
• CRUD（Create, Read, Update, Delete）に特化（SPMLはその他の操作を多数定義）
• シンプルで拡張しやすいユーザ・スキーマ（SPMLはDSML由来のため拡張が面倒）

　このように、クラウド・サービスにフォーカスしたシンプルな仕様を目指しているSCIMだが、SPMLと異なるのは、この仕様策定の方針だけではない。もう一つの大きな違いは、SPMLのときにはBMCやSunなどのプロビジョニング製品ベンダが中心となっていたが、SCIMでは、GoogleやSalesforce.com、Cisco（WebEx）、VMwareといった有力なCSPが積極的に仕様策定の議論に関与している点である。これはSCIMの利用可能な局面が多くなることを意味しており、実際に、企業とクラウド・サービスを連携させる製品・サービスのベンダーや、他の中小CSPも、SCIMコミュニティに続々と参加している。
　SCIM仕様の策定は、クラウドベースのアプリケーションやサービスのユーザ情報の管理を容易にすることを目的に進められている。また既存のスキーマや導入パターン、認証・認可モデルを活用し、仕様自身はシンプルに留める方針である。そのため仕様としては、「プロトコル」、「スキーマ」および「バインディング」の3種類のドキュメントにまとめられている。

(2) ユースケース

　SCIMコミュニティが作成した SCIMシナリオ [4] では、どのような用途にSCIMプロトコルを適用するかが紹介されている。まずどのアクター（関与するエンティティ）間にてSCIMを利用するかについては、ECSとCSPの間と、あるCSPと別のCSPの間のフローが挙げられている。前者は典型的には企業内のID管理システムからクラウド・サービスへのプロビジョニングであり、後者は例えばクラウド・サービスのマーケットプレイスから、そこに出店する別のクラウド・サービスへのプロビジョニングである。またフローには、プッシュ（例：ユーザ生成を他所に反映）／プル（例：他所からの変更通知を受け取り、ユーザの最新の属性情報を取得）のふたつの向きがあることが示されている。
　そして、SCIMプロトコルを開始する起点が「トリガー」である。同文書では5種類のトリガーを規定している。

• 生成（Create）：新入社員の登録や、サービス利用契約の締結に基づく、CSP上のアイデンティティ・リソース（アカウント情報）の生成


• 変更（Update）：ユーザのパスワード初期化、あるいはサービス利用契約のプラン変更などに基づく、CSP 上のアイデンティティ・リソースの更新


• 削除（Delete）：社員の休職・退職や、サービス利用契約の終了に基づく、CSP上のアイデンティティ・リソースの削除や無効化


• 同期（Sync）：社員の属性情報の変更に基づく、アクター間での変更内容の伝播


• シングル・サインオン（SSO）：CSU（クラウド・サービス・ユーザ： ECSに所属するユーザ）がCSPにアクセスを試みたタイミングで、シングル・サインオンと同時に、アイデンティティ・リソースの生成や変更を通知

　ECSがCSPにアイデンティティ・リソースの生成をリクエストし、そしてそのCSPが別のCSPに対してさらにアイデンティティ・リソースの生成をリクエストするユースケースを下図に示す（図1）。

図1：ECSを起点とする複数CSPへのアイデンティティ・リソース生成のユースケース
（出典： http://www.simplecloud.info/specs/draft-scim-scenarios-04.html）

(3) SCIMプロトコル

　前述のトリガーに基づく処理を規定しているのが、SCIMプロトコル [5] である。
　SCIMプロトコルは RESTful APIを指向している。クライアント（Webサイトやアプリケーション）はサービス・プロバイダ（SCIMプロトコルを受けつけるWeb サイト）に対し、下記のHTTPメソッドを利用してリソース（ユーザ、グループ、パスワード）操作のリクエストを発行する。そしてサービス・プロバイダからクライアントへのレスポンスは、HTTPステータス・コードと、処理結果を含むボディから構成される。

• GET：リソース取得（全体/部分）
• POST：新規リソース生成
• PUT：リソースの変更（指定した内容で置き換え）
• PATCH：リソースの変更（部分更新）、パスワード変更
• DELETE：リソース削除

　APIエンドポイントは各リソースを単位として、下記のように定義されている（表1)。

表1: 定義済みのエンドポイント

（出典：http://www.simplecloud.info/specs/draft-scim-rest-api-01.html#endpoint-summary）

　ユーザ情報生成のリクエスト・レスポンスの例を以下に示す。リクエストはユーザ情報を POST することによって行われる。そしてレスポンスでは、当該リソースの場所が Location ヘッダとして、リソースの表現がボディとして返却される。

POST /User HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...


{
  "schemas":["urn:scim:schemas:core:1.0"],
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  }
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/v1/User/uid=bjensen,dc=example,dc=com
ETag: "e180ee84f0671b1"


{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"uid=bjensen,dc=example,dc=com",
  "meta":{
    "created":"2011-08-01T21:32:44.882Z",
    "lastModified":"2011-08-01T21:32:44.882Z"
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen"
}

　なおAPIアクセスに関する認証・認可の方法は、SCIMの仕様上では定義・指定しないが、OAuth 2.0 [6] の利用を推奨している。

(4) スキーマ

　コア・スキーマ [7] では、ユーザ/グループを表現する最小限のスキーマと、スキーマの拡張モデルを定義している。
　SCIM のスキーマ定義は、既存のクラウド・サービス事業者のAPI、Portable Contacts [8]、LDAPなどを参考にしている。現在定義されているスキーマは以下の通り。

• ユーザ（urn:scim:schemas:core:user:1.0)
• エンタープライズ・ユーザ（urn:scim:schemas:extension:user:enterprise:1.0)
• グループ（urn:scim:schemas:core:group:1.0)

　スキーマの拡張モデルとしては、LDAPのObjectClassの考え方を援用している。ただしシンプルさを維持するため、LDAPと異なりスキーマの継承はない。
またスキーマの表現方法としては、JSON 形式ならびに XML 形式の両方が可能となっている。それぞれの例を以下に示す。

{
    "schemas":["urn:scim:schemas:core:user:1.0", 
 "urn:scim:schemas:extension:user:enterprise:1.0"],
    "id": "005D0000001Az1u",
    "externalId": "701984",
    "userName": "bjensen@example.com",
    "name": {
    	"formatted": "Ms. Barbara J Jensen III",
        "familyName": "Jensen",
        "givenName": "Barbara",
        "middleName": "Jane",
        "honorificPrefix": "Ms.",
        "honorificSuffix": "III"
    },
    "displayName": "Babs Jensen",
    "nickName": "Babs",
    "profileUrl": "https://login.example.com/bjensen",
    "emails": [
        {
          "value": "bjensen@example.com",
          "type": "work",
          "primary": true
        },
        {
          "value": "babs@jensen.org",
          "type": "home"
        }
    ],
(略)
    "meta": {
        "created": "2010-01-23T04:56:22Z",
        "lastModified": "2011-05-13T04:42:34Z"
    }
}

<SCIM xmlns="urn:scim:schemas:core:user:1.0" 
xmlns:enterprise="urn:scim:schemas:extension:user:enterprise:1.0">
    <id>005D0000001Az1u</id>
    <externalId>701984</externalId>
    <userName>bjensen@example.com</userName>
    <name>
    	<formatted>Ms. Babs J Jensen III</formatted>
    	<familyName>Jensen</familyName>
    	<givenName>Barbara</givenName>
    	<middleName>Jane</middleName>
    	<honorificPrefix>Ms.</honorificPrefix>
    	<honorificSuffix>III</honorificSuffix>
    </name>
    <displayName>Babs Jensen</displayName>
    <nickName>Babs</nickName>
    <profileUrl>https://login.example.com/bjensen</profileUrl>
    <emails>
        <email type="work" primary="true">bjensen@example.com</email>
        <email type="home">babs@jensen.com</email>
    </emails>
(略)
    <meta>
        <created>2010-01-23T04:56:22Z</created>
        <lastModified>2011-05-13T04:42:34Z</lastModified>
    </meta>
</SCIM>

(5) バインディング

　SCIM のスキーマやプロトコルを別のプロトコル仕様と組み合わせて利用するための規定を、バインディングと呼ぶ。
　現在、SCIMメッセージをSAML SSO（SAML Web SSOプロファイル）に載せるためのバインディングとして SAML 2.0 Binding for SCIM [9] が定義されている。これは、SSOと同時にアカウントを作成したり、属性情報を更新する、いわゆる「Just-in-time プロビジョニング」（ユーザが利用する前に事前設定するのではなく、ユーザの初回利用と同時にアカウント生成やアクセス権限設定を実施）を目的としている。同バインディングでは、下記の方法を定義している。

• SCIMのユーザ属性からSAML属性へのマッピング
• SAML SSOアサーションにSCIMのユーザ属性を記述する方法
• SAML AttributeQueryを用いたSCIMユーザ属性の取得
• SAMLメタデータによる、サポートするSCIM属性の公告

　今後のスケジュールとしては、下記のように予定されている。

• 2011年10月：IIW（Internet Identity Workshop）にてデモンストレーション
• 同月末：バージョン 1.0 Draft 1 公開
• 11月30日：相互運用性テスト開催
• その後、バージョン 1.0 を確定し、IETF（Inernet Engineering Task Force）などの標準化機関に策定を移管する予定

　アイデンティティ・プロビジョニングAPIの標準化の必要性は、従来より業界内で認識されており、SPMLが有望な仕様とされていたが、広く普及するまでに至らなかった。これに対し、有力クラウド・サービス・プロバイダを中心とするメンバーが、各ベンダー独自のプロビジョニングAPIの共通化を目指し、SCIMを策定する動きに出ている。
　今後、早い段階での仕様確定と実サービスへの適用が行われれば、他のクラウド・サービス・プロバイダやアイデンティティ・プロビジョニング製品ベンダーの採用が進むものと考えられる。

以上