あぶない 刑事 パチンコk8 カジノ第6回 Salesforce CRM/Force.comとのアイデンティティ基盤連携を実現する(後)仮想通貨カジノパチンコダズンベット 攻略

あぶない 刑事 パチンコk8 カジノ第6回 Salesforce CRM/Force.comとのアイデンティティ基盤連携を実現する(後)仮想通貨カジノパチンコダズンベット 攻略

あぶない 刑事 パチンコk8 カジノ第6回 Salesforce CRM/Force.comとのアイデンティティ基盤連携を実現する(後)仮想通貨カジノパチンコダズンベット 攻略

新作 無料 ゲーム pck8 カジノ クラウド・サービスと社内システムとのID連携 最新トレンドWindows Server Insider

ばく サイ パチンコ 青森

「クラウド・サービスと社内システムとのID連携 最新トレンド」のインデックス

連載目次

 第5回では社内のActive Directory(AD)とSalesforce CRMへのシングル・サインオン(SSO)を行うための設定および動作確認について解説した。今回は、Salesforce CRM上にユーザーを動的に作成するジャスト・イン・タイム・プロビジョニングの設定と動作確認を行う。

Salesforce CRMと社内Active Directoryの連携環境Salesforce CRMと社内Active Directoryの連携環境ジャスト・イン・タイム・プロビジョニングの設定

 まず、「ジャスト・イン・タイム・プロビジョニング」について解説をしておく。通常シングル・サインオンを行うためには、前もってサービス側にユーザーを作成(プロビジョニング)しておく必要がある。だがエクストラ・ネット利用者など、事前に情報を収集してユーザーを作成しておくことが困難なケースでは、シングル・サインオンの際に利用するトークンの中のユーザー情報を利用して、サインオン時にユーザーを動的に作ってしまうこともある。この仕組みをジャスト・イン・タイム・プロビジョニングと呼ぶ。

パターンユーザーの作成(プロビジョニング)連携するID情報通常のプロビジョニングとシングル・サインオン事前に作成認証情報のみを連携ジャスト・イン・タイム・プロビジョニングID連携時に作成認証情報に加えてユーザー作成に必要な属性情報も連携ID連携のパターンとプロビジョニング事前にユーザーを作成することが困難な場合、サインオン時(ID連携時)にプロビジョニングすなわちユーザー作成を動的に実行することもある。それをジャスト・イン・タイム・プロビジョニングと呼ぶ。

 実際にSalesforce CRMのジャスト・イン・タイム・プロビジョニングを実現するには、以下の2つのステップを実行する必要がある。

Salesforce CRMでプロビジョニングを有効化するAD FS 2.0でプロビジョニングに必要な属性をトークンに含めるための設定を行う

 では、順番に設定を行っていく。

●Salesforce CRMでプロビジョニングを有効化する

 前回解説したシングル・サインオン設定の際と同様に、Salesforce CRMに管理者アカウントでログインし、プロビジョニングを有効化する。設定は非常にシンプルで、シングル・サインオンの設定時と同じく[シングルサインオン設定]のページを開き、その中にある[ユーザプロビジョニングの有効化]にチェックを入れてオンにするだけだ。

プロビジョニングを有効化するプロビジョニングを有効化するシングル・サインオンの設定と同様に、Salesforce CRMのログイン・ページから管理者アカウントでログイン後、アカウントの[設定]より[管理者設定]-[セキュリティのコントロール]-[シングルサインオン設定]の順にメニューを開くと、このページが表示される。 (1)チェックを入れてオンにする。●AD FS 2.0でプロビジョニングに必要な属性をトークンに含めるための設定を行う

 Salesforce CRMへのジャスト・イン・タイム・プロビジョニングを実行するためには、AD FS 2.0が発行するトークンに下表の属性を含める必要がある。

属性Salesforceでの属性名設定値EmailUser.EmailAD DSのメール・アドレス属性(「電子メール」属性)LastNameUser.LastNameAD DSの「姓」属性ProfileIdUser.ProfileID固定文字列としてSalesforce CRMのプロファイルIDを設定※「Chatter Free User」などのプロファイル名も指定可UserNameUser.UserNameAD 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属性を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」属性のためのカスタム規則の設定内容

 同じく、実際に作成した規則はこのようになる。

ProfileID属性をSalesforce CRM向けに発行するためのカスタム規則ProfileID属性をSalesforce CRM向けに発行するためのカスタム規則これによってProfileID属性に「Chatter Free User」という固定の文字列が設定される。

 ここまでで合計3つの要求規則を設定したことになる。

設定した要求規則設定した要求規則合計3つの要求規則が作成されているはずだ。 (1)前回作成した要求規則。 (2)Email/LastName/UserNameの各属性のために作成した要求規則。 (3)ProfileID属性のために作成した要求規則。

 これでAD FS 2.0の設定は完了である。

ジャスト・イン・タイム・プロビジョニング動作の確認

 では、さっそくジャスト・イン・タイム・プロビジョニングの動作を確認していく。基本は前回の「シングル・サインオン動作の確認」と同じ手順だが、違いは前もってSalesforce CRM側にユーザーを作成しておく必要がない点だ。

 まずはAD DSにメール・アドレス属性(電子メール属性)を持つユーザーを作成する。

社内AD上に作成したユーザー社内AD上に作成したユーザーこのユーザーでSalesforce CRMにシングル・サインオンを行う。 (1)メール・アドレスを入力する。

 このユーザーを使って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の認証プロバイダ設定画面Salesforce CRMの認証プロバイダ設定画面

 設定後にSalesforce CRMへのログインを行うとFacebookでの認証が実行され、Facebookから取得した情報を基にSalesforce CRM上のアカウントとのリンクが作成され、ログオン(シングル・サインオン)が行われる。

FacebookアカウントとSalesforce CRMのアカウントのリンクFacebookアカウントとSalesforce CRMのアカウントのリンク

 ほかにもForce.com自身をIdPとして利用する機能として「ID プロバイダ」という機能もあり、Google AppsなどのSAML 2.0に対応したサービスへForce.com上のユーザーでシングル・サインオンすることも可能である。

Force.comをIdPとしてGoogle Appsを利用するための設定Force.comをIdPとしてGoogle Appsを利用するための設定

 このようにクラウド上のサービス自体がアイデンティティ管理や連携を行うという「IDMaaS(Identity Management as a Service: サービスとしてのID管理システム)」シナリオが現実味を帯びてきている。特に中小企業やスタートアップ企業など自社に基盤を持たない(持ちたくない)企業にとっては、利便性とセキュリティを両立するための選択肢が増えてきているのは歓迎すべきことであり、今後もこの流れは加速していくと考えられるのではないだろうか。


 前後編の2回にわたって、社内ADとSalesforce CRMへのシングル・サインオンおよびジャスト・イン・タイム・プロビジョニングを実現するための設定と動作確認について解説した。次回は最終回となるが、これまでのように社内ADを使って社外のサービスへのアクセスを行うのではなく、Windows Azure Active DirectoryのAccess Control Service機能を活用して、ECサイトなど顧客向けに提供するサービスをFacebookやGoogleアカウントなどのソーシャルIDで利用する、というシナリオを紹介する予定だ。

« 前の回へ

次の回へ »

「クラウド・サービスと社内システムとのID連携 最新トレンド」のインデックス

「クラウド・サービスと社内システムとのID連携 最新トレンド」

仮想通貨カジノパチンコラグビー ラグビー トップ リーグ

Leave a Reply