salesforce.com summer'11 の JIT Provisioning を試してみる

salesforce.com の summer'11 版の新機能で Just In Time Provisioning（JIT Provisioning）が追加されているのを発見したのでちょっとAD FS2.0との連携動作を確認してみました。

■JIT Provisioning とは
試してみる前にまず、JIT Provisioning とはなんなのか？を簡単に解説しておきます。

一言で言うと「SAML 等の Assertion からユーザを On the Fly で作成する」ということです。これまで一般的にシステムへのシングルサインオンをする前提はそのシステムに「あらかじめ」ユーザが作成されていることが必要でした。しかし、クラウド上のシステムへあらかじめユーザを作成する＝クラウド上にユーザ情報をある程度持たせる必要がある、という点に抵抗感があったり、あくまでオンプレミスとクラウドの間で疎なシステム結合を行いたい、というニーズに対して登場してきたのが JIT Provisioning です。 動作としては、例えばSAMLでのシングルサインオンを行うような場合に、IdP から発行されるセキュリティトークンの中にある Assertion (クレーム）を元にユーザを作成する、という動きです。

・従来のプロビジョニング～シングルサインオン

・JIT プロビジョニング～シングルサインオン




■salesforce.com における JIT Provisioning 設定

では、早速設定を確認してみます。

まずは salesforce.com 側の設定です。今回は force.com を使っていますが、基本的な設定は salesforce.com でも同様です。

基本的な設定方法は以前 @IT に書いた記事を参考に実施をして行くことになります。
　Windowsで構築する、クラウド・サービスと社内システムのSSO環境 第3回 　http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso03/adfs2sso03_04.html


記事と異なる点は以下の通りです。

・salesforce 側のシングルサインオン設定 　

 Force.com のセキュリティ設定の中のシングルサインオン設定で、以下を設定します。 　
 ・ユーザプロビジョニングの有効化：チェック 　
 ・SAML のユーザ ID 種別：アサーションには、ユーザオブジェクトの統合 ID が含まれます

・プロファイルの作成 　

 JIT Provisioning の前提として、SAML アサーションの Attribute フィールドの中に最低でも 　
 ・Username 　
 ・Email 　
 ・LastName 　
 ・ProfileId
 が入っている必要があります。 　
 参考）http://login.salesforce.com/help/doc/en/sso_jit_requirements.htm

 UserName や Email などはわかりやすい属性なので、特にこの段階で意識をする必要はありませんが、 ProfileId だけは force.com の管理画面からも見ることが出来ません。（本来は 00ex0000001pBNL などといった識別子のようです）頑張ってAPEX等でコードを書いて実際のIDを取得しても良いのですが、敷居が高いので同じ属性にプロファイル名を入れると force.com 側で勝手に ID へ変換してくれるので今回はそちらを使います。

 ただ、ビルトインのプロファイル名（ Force.com - Free User など）はうまく識別をしてくれなかったので、今回は新たに単純に「 User 」という名前のプロファイルを作りました。（ Force.com - Free User をテンプレートとして作成したので内容は全く同じです）

・AD FS2.0 側のクレーム発行ルール

 次に AD FS2.0 側ですが、通常の SSO 設定と同様に Active Directory の UPN やメールアドレスを NameIdentifier に入れてあげる点に加え、上記にも書いた JIT Provisioning に必要な各属性に関するルールの記述が必要です。

 その際に、各属性名のプレフィックスに「 User. 」をつけてあげる必要があります。 　具体的には、以下の様なマッピングを行います。

発行するクレームタイプ	データソース	値
NameIdentifier	Active Directory	UPN or メールアドレス（今回は UPN を利用）
User.Username		メールアドレス
User.Email		メールアドレス
User.LastName		姓
User.ProfileId	固定値	「User」

 Username、Email、LastName についてのクレーム発行ルールはカスタムで以下の様に記述しています。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("User.Username", "User.Email", "User.LastName"), query = ";mail,mail,sn;{0}", param = c.Value);

同様に、ProfileId については以下の様に記述しています。

 => issue(Type = "User.ProfileID", Value = "User", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified");

■実際の動作確認

では、いよいよ動作を確認します。

まず、 force.com 側にあらかじめユーザが存在しないことを確認するためにユーザ一覧を見ておきます。

この状態で Active Directory 上に新規ユーザを作成し、AD FS2.0 で認証後、force.com へアクセスします。IdP Initiated ログオンをしますので、
 https://[AD FS2.0サーバ]/adfs/ls/idpinitiatedsignon.aspx?loginToRp=https://saml.salesforce.com
へのアクセスをします。

　-　新規ユーザ

- AD FS2.0 で認証

















すると、うまくいけばあらかじめプロビジョニングしているわけではないのに、force.com へログインできます。

では、実際に force.com にユーザが作成されているかどうかを確認するために管理コンソールでユーザ一覧を見てみます。

見事にユーザが出来ています。


■ JIT Provisioning の利点と注意点

　この仕組みの最大の利点はあらかじめプロビジョニングをしておく必要がない＝ ID 管理システムの構築やアダプタの開発などをしなくても済む、という点です。

　反面、注意しなければならないポイントもあります。 例えば、
　・ユーザの削除は手動でしなければならない
　・利用者の数が予測しにくいのでライセンス管理が必要である
　・ユーザ同士でのコラボレーションをしたくても相手が一度もログインしたことがなければシステム上にユーザが存在しないので情報共有などが出来ない
　などが挙げられます。

　このように万能ではありませんが、別の仕組みや運用と合わせてある程度のガバナンスを保ったうえで利用するには非常に有用な仕組みと言えると思います。