第6回 Salesforce CRM／Force.comとのアイデンティティ基盤連携を実現する（後）：クラウド・サービスと社内システムとのID連携 最新トレンド
事前にユーザーを作成することなく、社内Active DirectoryとSalesforce CRMへのシングル・サインオンを可能にする「ジャスト・イン・タイム・プロビジョニング」の設定方法を解説する。
第5回では社内のActive Directory（AD）とSalesforce CRMへのシングル・サインオン（SSO）を行うための設定および動作確認について解説した。今回は、Salesforce CRM上にユーザーを動的に作成するジャスト・イン・タイム・プロビジョニングの設定と動作確認を行う。
ジャスト・イン・タイム・プロビジョニングの設定
まず、「ジャスト・イン・タイム・プロビジョニング」について解説をしておく。通常シングル・サインオンを行うためには、前もってサービス側にユーザーを作成（プロビジョニング）しておく必要がある。だがエクストラ・ネット利用者など、事前に情報を収集してユーザーを作成しておくことが困難なケースでは、シングル・サインオンの際に利用するトークンの中のユーザー情報を利用して、サインオン時にユーザーを動的に作ってしまうこともある。この仕組みをジャスト・イン・タイム・プロビジョニングと呼ぶ。
| パターン | ユーザーの作成（プロビジョニング） | 連携するID情報 |
|---|---|---|
| 通常のプロビジョニングとシングル・サインオン | 事前に作成 | 認証情報のみを連携 |
| ジャスト・イン・タイム・プロビジョニング | ID連携時に作成 | 認証情報に加えてユーザー作成に必要な属性情報も連携 |
| ID連携のパターンとプロビジョニング 事前にユーザーを作成することが困難な場合、サインオン時（ID連携時）にプロビジョニングすなわちユーザー作成を動的に実行することもある。それをジャスト・イン・タイム・プロビジョニングと呼ぶ。 | ||
実際にSalesforce CRMのジャスト・イン・タイム・プロビジョニングを実現するには、以下の2つのステップを実行する必要がある。
では、順番に設定を行っていく。
●Salesforce CRMでプロビジョニングを有効化する
前回解説したシングル・サインオン設定の際と同様に、Salesforce CRMに管理者アカウントでログインし、プロビジョニングを有効化する。設定は非常にシンプルで、シングル・サインオンの設定時と同じく［シングルサインオン設定］のページを開き、その中にある［ユーザプロビジョニングの有効化］にチェックを入れてオンにするだけだ。
プロビジョニングを有効化する
シングル・サインオンの設定と同様に、Salesforce CRMのログイン・ページから管理者アカウントでログイン後、アカウントの［設定］より［管理者設定］−［セキュリティのコントロール］−［シングルサインオン設定］の順にメニューを開くと、このページが表示される。
（1）チェックを入れてオンにする。
●AD FS 2.0でプロビジョニングに必要な属性をトークンに含めるための設定を行う
Salesforce CRMへのジャスト・イン・タイム・プロビジョニングを実行するためには、AD FS 2.0が発行するトークンに下表の属性を含める必要がある。
| 属性 | Salesforceでの属性名 | 設定値 |
|---|---|---|
| User.Email | AD DSのメール・アドレス属性（「電子メール」属性） | |
| LastName | User.LastName | AD DSの「姓」属性 |
| ProfileId | User.ProfileID | 固定文字列としてSalesforce CRMのプロファイルIDを設定 ※「Chatter Free User」などのプロファイル名も指定可 |
| UserName | User.UserName | AD DSのメール・アドレス属性 |
| トークンに含める属性（必須属性のみ） なお、属性フォーマットは「urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified」を利用する必要がある。 ・（参考）ジャスト・イン・タイム・プロビジョニングの要件（セールスフォース・ドットコム） | ||
上記を踏まえ、AD FS 2.0のカスタム要求規則を作成する。カスタム規則を作成するには、要求規則を追加する際に要求規則テンプレートに［カスタム規則を使用して要求を送信］を選択する。なお、前回解説したシングル・サインオンの設定時に作成した要求規則はジャスト・イン・タイム・プロビジョニングを行う際も必要になるので、そのまま残しておき、今回作成するカスタム規則を追加で設定する。
要求規則テンプレートとしてカスタムを選択
前回の「AD FS 2.0の証明書利用者信頼にSalesforce CRMの設定を追加する」と同様の手順で要求規則を追加する（前回作成した要求規則は残しておくこと）。
（1）［カスタム規則を使用して要求を送信］を選んで、次へ進む。
まずは「Email」「LastName」「UserName」属性をAD DSの各属性とマッピングするために以下のカスタム規則を作成する。
| 項目 | 設定値 |
|---|---|
| 要求規則名 | Attributes for JIT Provisioning（任意の名称） |
| カスタム規則 | 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); |
| 「Email」「LastName」「UserName」属性のためのカスタム規則の設定内容 | |
実際の作成した規則はこのようになる。
Email／LastName／UserName属性をSalesforce CRM向けに発行するためのカスタム規則
これによってEmail／LastName／UserName属性とAD DSの各属性とをマッピングできる。
上記と同じ手順で、今度は「ProfileID」として固定文字列「Chatter Free User」を設定するカスタム規則を作成する。
| 項目 | 設定値 |
|---|---|
| 要求規則名 | ProfileId for JIT Provisioning（任意の名称） |
| カスタム規則 | => issue(Type = "User.ProfileID", Value = "Chatter Free User", Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"); |
| 「ProfileID」属性のためのカスタム規則の設定内容 | |
同じく、実際に作成した規則はこのようになる。
ここまでで合計3つの要求規則を設定したことになる。
設定した要求規則
合計3つの要求規則が作成されているはずだ。
（1）前回作成した要求規則。
（2）Email／LastName／UserNameの各属性のために作成した要求規則。
（3）ProfileID属性のために作成した要求規則。
これでAD FS 2.0の設定は完了である。
ジャスト・イン・タイム・プロビジョニング動作の確認
では、さっそくジャスト・イン・タイム・プロビジョニングの動作を確認していく。基本は前回の「シングル・サインオン動作の確認」と同じ手順だが、違いは前もってSalesforce CRM側にユーザーを作成しておく必要がない点だ。
まずはAD DSにメール・アドレス属性（電子メール属性）を持つユーザーを作成する。
このユーザーを使ってAD FS 2.0を経由してSalesforce CRMへシングル・サインオンを行う（「https://＜AD FS 2.0サーバのアドレス＞/adfs/ls/IdpInitiatedSignOn.aspx」を開いてサインインを実行する）。するとSalesforce CRM側にユーザーを作成していないにも関わらずログオンができたはずだ。
管理者アカウントでSalesforce CRM上のユーザー一覧を表示するとユーザーが新規に作成されていることが分かる。
ジャスト・イン・タイム・プロビジョニングにより作成されたユーザー
これは動作確認後に管理者アカウントでSalesforce CRMにログインし、ユーザー一覧を表示したところ。
（1）新たに作成されたユーザー。前述の要求規則でProfileID属性に指定した「Chatter Free User」というプロファイルが用いられていることが分かる。
【コラム】IDMaaS（サービスとしてのID管理システム）としてのSalesforce CRM／Force.com
余談ではあるが、Salesforce CRMやForce.comには自身をIdP（アイデンティティ・プロバイダ）として設定する機能や、FacebookのようなソーシャルIDとの連携などを行う機能が存在する。また、2012年秋のセールスフォース・ドットコムのイベント「Dreamforce ‘12」で発表されたようにSCIM（System for Cross-domain Identity Management： クラウドへのプロビジョニングの標準仕様）やOpenID Connectへの対応も着々と進んでおり、Salesforce CRM／Force.comをクラウド上でのID管理基盤として利用できるようになる日も近いと思われる。
- （参考）Introducing Salesforce Identity（セールスフォース・ドットコムのChuck Mortimore氏のブログ）
詳しい手順は省略するが、一例としてFacebookをSalesforce CRMの外部認証プロバイダとして設定し、FacebookユーザーでSalesforce CRMを利用する例を紹介する。
大まかな手順は以下の通りである。
- Facebookの開発ツールでSalesforce連携用のアプリケーションを作成する
- FacebookでログオンするWebサイトとしてSalesforce CRMを指定
- コンシューマ・キーとコンシューマ・シークレットの取得
- Salesforce CRMの認証プロバイダとして作成したFacebookアプリケーションの設定を行う
- コンシューマ・キーとコンシューマ・シークレットの設定、登録ハンドラの設定
- Salesforce CRM上にカスタム・ハンドラを作成し、Facebookから取得したユーザー情報とSalesforce CRM内のユーザーのひも付け処理を定義する
- ユーザー作成時、リンク時の動作の定義
一部のAPEXコードをカスタマイズする必要があるが、基本的なコードのテンプレートはあらかじめ用意されているので、それほど困難な作業ではない。
設定後にSalesforce CRMへのログインを行うとFacebookでの認証が実行され、Facebookから取得した情報を基にSalesforce CRM上のアカウントとのリンクが作成され、ログオン（シングル・サインオン）が行われる。
ほかにもForce.com自身をIdPとして利用する機能として「ID プロバイダ」という機能もあり、Google AppsなどのSAML 2.0に対応したサービスへForce.com上のユーザーでシングル・サインオンすることも可能である。
このようにクラウド上のサービス自体がアイデンティティ管理や連携を行うという「IDMaaS（Identity Management as a Service： サービスとしてのID管理システム）」シナリオが現実味を帯びてきている。特に中小企業やスタートアップ企業など自社に基盤を持たない（持ちたくない）企業にとっては、利便性とセキュリティを両立するための選択肢が増えてきているのは歓迎すべきことであり、今後もこの流れは加速していくと考えられるのではないだろうか。
前後編の2回にわたって、社内ADとSalesforce CRMへのシングル・サインオンおよびジャスト・イン・タイム・プロビジョニングを実現するための設定と動作確認について解説した。次回は最終回となるが、これまでのように社内ADを使って社外のサービスへのアクセスを行うのではなく、Windows Azure Active DirectoryのAccess Control Service機能を活用して、ECサイトなど顧客向けに提供するサービスをFacebookやGoogleアカウントなどのソーシャルIDで利用する、というシナリオを紹介する予定だ。
Copyright© Digital Advantage Corp. All Rights Reserved.