Microsoft AD FS を ID プロバイダーとして使用した Salesforce への SSO の設定

前提条件

AD FS 2.0 を Salesforce ID プロバイダーとして設定するには、以下が必要です。

• Microsoft Windows Server 2008 R2 Enterprise または Datacenter エディション。評価目的で環境を設定する場合は、Microsoft ダウンロードセンターからトライアルバージョンをダウンロードできます。
• Microsoft Active Directory フェデレーションサービス 2.0。
  

  メモ Windows Server 2008 R2 に含まれる AD FS 1.0 は SAML 2.0 をサポートしていません。 そのため、AD FS 2.0 RTW (Release To Web) パッケージをダウンロードします。
• Salesforce 組織。Developer Edition 環境で試すことができます。

概要

SAML 2.0 では、SSO への参加者のロールが定義されています。ユーザーは ID プロバイダー (IdP) (この場合は AD FS 2.0) に対して認証します。 ユーザーは 1 つ以上のサービスプロバイダー (SP) のリソースに、各サービスプロバイダーにログインすることなくアクセスできるようになります。この場合の SP (「証明書利用者」とも呼ばれる) は Salesforce 組織です。

次の図は、IdP が開始する Salesforce へのログインプロセスを示します。

• ユーザーが統合 Windows 認証 (HTTP 経由の Kerberos トークン) を使用して AD FS サーバーに対する認証を行い、Salesforce へのログインを要求します。(1)。
• AD FS が SAML アサーションをユーザーのブラウザーに返します。(2)
• ブラウザーがアサーションを Salesforce に送信し、Salesforce がユーザーをログインします。(3)

以下はテストリリースを作成するための概要手順です。

1. Microsoft AD FS 2.0 をインストールする。
2. AD FS と Salesforce 環境を設定する。
3. 設定をテストする。
4. 必要に応じて実装の問題をトラブルシューティングする。

ソフトウェアのインストール

1. まず Windows Server 2008 R2 をインストールします。
   

   メモ AD FS サーバーは Active Directory ドメインのメンバーである必要があります。評価目的でラボ設定を構築する場合、AD FS サーバーをドメインコントローラーにすることができます。ただし、この設定は本番設定にはお勧めしません。
2. AD FS にわかりやすい DNS 名を作成し (例: adfs.testzone.local)、AD FS 2.0 サーバーを参照するように指定します。
3. AD FS 2.0 をダウンロードしてインストールします。 このステップでは、前提となる他の Windows コンポーネント (IIS など) をインストールします。
4. IIS マネージャーで、わかりやすい DNS 名に対する SSL 証明書を作成します。IIS 6.0 リソースキットがある場合は、SelfSSL を使用して自己署名証明書を作成できます。
5. AD FS サーバー設定ウィザードを実行します。
   1. フェデレーションサービスを作成します。
   2. [Stand-alone Server (スタンドアロンサーバー)] を選択します。
   3. わかりやすい DNS 名に対して作成した証明書を選択します。
6. インストーラーがサービスプリンシパル名 (SPN) を登録するときにエラーが発生したら、その DNS 名に対して手動で Kerberos SPN を作成します。この SPN により、統合 Windows 認証はブラウザーと AD FS IIS インスタンス間で適切に機能できます。

1  setspn -a HOST/adfs.testzone.local testzone\ADFSSVR01

2  setspn -a HOST/adfs testzone\ADFSSVR01

Kerberos SPN についての詳細は、「Active Directory and Kerberos SPNs Made Easy」 (Active Directory と Kerberos SPN についての簡単な説明) を参照してください。

Salesforce の設定

2 者間にフェデレーションを構築するには、メタデータを交換して信頼関係を確立する必要があります。AD FS 2.0 インスタンスのメタデータは Salesforce の設定に入力されます。Salesforce のメタデータは AD FS 2.0 で使用可能な XML ファイルとしてダウンロードされます。

SAML 2.0 の設定

AD FS 2.0 MMC Snap-in で、証明書ノードを選択し、トークン署名証明書をダブルクリックして表示します。[詳細] タブをクリックし、[ファイルにコピー] を選択します。証明書を DER 形式で保存します。

AD FS サーバーで、AD FS MMC の [Service (サービス)] | [Endpoints (エンドポイント)] | [Metadata (メタデータ)] | [Type:Federation Metadata (Type:Federation メタデータ)] にある統合メタデータ URL を参照します。この例では、URL は https://adfs.testzone.local/FederationMetadata/2007-06/FederationMetadata.xml です。

entityID 属性の値をコピーします。この例では、値は http://adfs.testzone.local です。

Salesforce で、[設定] から [クイック検索] ボックスに「シングルサインオン」と入力し、[シングルサインオン設定] を選択します。[SAML を有効化] を選択し、SAML SSO 設定を作成するオプションをクリックします。

メモ [統合 ID を大文字と小文字を区別しない] 設定は、SAML を初めて有効にするときにデフォルトで有効になっています。この設定により、csmith や CSmith など、類似する統合 ID を持つ一意のユーザーを作成できなくなります。この設定は有効にしておくことをお勧めします。

設定を定義します。

• 名前 — SAML SSO 設定の名前を入力します。
• SAML のバージョン — 2.0 に設定されています。
• 発行者 — 上記の entityID をここに貼り付けます。
• ID プロバイダーの証明書 — 前にエクスポートしたトークン署名証明書を参照して選択します。
• 証明書の署名要求 — 前に作成した自己署名証明書を選択します。(自己署名証明書の生成手順を参照してください)。
• 署名要求メソッド — [RSA-SHA-1] に設定します。
• SAML ID 種別 — ユーザーをログインするために、Salesforce ユーザー名または統合 ID のいずれかと照合できます。 統合 ID と照合する場合、統合 ID がすべてのユーザーのプロファイルに入力されている必要があります。テストでは、統合 ID を選択します。 ユーザーが Salesforce ユーザー名としてメールアドレスを使用する場合は、本番リリースでユーザー名との照合に切り替えることができます。
• SAML ID の場所 — ユーザーをログインするために、SAML アサーションの NameID か、別の属性を使用できます。AD FS では SAML アサーションに NameID が入力されるため、NameID を使用できます。
• サービスプロバイダーの起動要求バインド — [HTTP リダイレクト] を選択することをお勧めします。
• ID プロバイダーのログイン URL — AD FS SAML エンドポイントの URL を入力します。この URL に Salesforce から SP で開始されるログインへの SAML 要求が送信されます。
  

  メモ URL の末尾にスラッシュを追加してください。

  この URL は、AD FS MMC の [Endpoints (エンドポイント)] | [Token Issuance (トークンの発行)] | [Type:SAML 2.0/WS-Federation] にあります。この例では、URL は https://adfs.testzone.local/adfs/ls/ です。

• カスタムログアウト URL — ログアウト後にユーザーがリダイレクトされる URL (例: http://intranet.mycompany.com/) を設定できます。
• エンティティ ID — AD FS IdP が Salesforce SP を識別する方法を指定します。SP が開始する SSO を有効にするには、設定済みの [私のドメイン] からエンティティ ID を入力します。

設定を保存し、メタデータ XML ファイルをダウンロードします。

AD FS 2.0 設定

Salesforce のメタデータを入手できたので、AD FS 側の信頼関係を作成します。AD FS 2.0 MMC Snap-in を開き、新しい「証明書利用者信頼」を追加します。

• Select Data Source (データソースを選択) — ファイルから証明書利用者に関するデータをインポートします。Salesforce からダウンロードした XML ファイルを参照します。
• Specify Display Name (表示名) — 信頼の表示名を指定します (例: Salesforce Test)。
• Choose Issuance Authorization Rules (発行承認ルールの選択) — すべてのユーザーにこの証明書利用者へのアクセスを許可します。
• Open Edit Claim Rules Dialog (要求ルールの編集ダイアログを開く) — 選択します。

要求ルールエディターで、[Issuance Transform Rules (発行変換ルール)] タブをクリックします。[Send LDAP Attributes as Claims (LDAP 属性を要求として送信)] に設定した [Claim Rule Template (要求ルールテンプレート)] を使用してルールを追加します。

• Claim Rule Name (要求ルール名) — テストでは、属性 User-Principal-Name に NameID が設定されるため、ルール名として「Send UPN as NameID」 (NameID として UPN を送信) を指定します。本番環境では、一般にユーザーのメールアドレスまたは従業員 ID を送信します。 属性の値が変わるとそのユーザーの SSO が無効になるため、将来的に値が変更される可能性が少ない属性を使用することが重要です。
• LDAP Attribute (LDAP 属性) — [User Principal Name (ユーザープリンシパル名)] を選択します。
• Outgoing Claim Type (送信要求種別) — [Name ID (名前 ID)] を選択します。

SP が開始するログイン

IdP が開始するログインプロセスでは、通常、会社のイントラネット上にリンクを設定し、ユーザーがそのリンクをクリックして Salesforce にアクセスできるようにします。SP が開始するログインプロセスは、ユーザーが Salesforce への直接リンクをクリックすると発生します。

Salesforce の SAML 設定に [私のドメイン] のエンティティ ID を設定すると (例: https://testinfo-developer-edition.my.salesforce.com)、ユーザーはそのドメインの URL に移動できます。その後、ユーザーは AD FS にリダイレクトされて認証されます。

Salesforce の SAML 設定に [私のドメイン] のエンティティ ID が設定されていると (例: https://testinfo-developer-edition.my.salesforce.com)、ユーザーはそのドメインの URL に移動できます。その後、ユーザーは AD FS にリダイレクトされて認証されます。

SP が開始するログインが機能するためには、AD FS のセキュアハッシュアルゴリズムパラメーターを SHA-1 に設定します。 Salesforce では SAML 要求への署名時に SHA-1 を使用しますが、AD FS のデフォルトは SHA-256 です。

SHA パラメーターは、AD FS で証明書利用者である Salesforce の信頼プロパティの [Advanced (詳細設定)] タブに設定します。

このパラメーターを設定しないと、AD FS イベントログにメッセージが表示されます。

Event ID: 378

SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . Expected signature algorithm is http://www.w3.org/2000/09/xmldsig#rsa-sha1

テスト

これで、Salesforce ユーザーの統合 ID に AD ユーザーアカウントの UPN を設定して、ログインプロセスをテストできます。

SP が開始するログインの場合、[私のドメイン] にエンティティ ID が設定されているという前提で、その URL を直接参照します (例: https://testinfo-developer-edition.my.salesforce.com)。

IdP が開始するログインの場合、AD FS ログイン URL を使用し、loginToRp パラメーターを Salesforce SAML エンティティ ID として指定します (例: https://adfs.testzone.local/adfs/ls/idpinitiatedsignon.aspx?loginToRp=https://saml.salesforce.com)。

どちらの場合でも、ブラウザーは一連のリダイレクトを行ってから、最終的に Salesforce 上のアプリケーションにログインします。Salesforce ログインエラーになった場合、Salesforce の SSO 設定ページの SAML アサーション検証ツールを使用します。ツールでは、最後に失敗した SAML ログインの結果が表示されます。

Ï

AD FS からエラーが返された場合、Server Manager\Diagnostics\Applications and Services Logs\AD FS 2.0\Admin にある AD FS ログを確認します。AD FS 2.0 の診断に関する MSDN のブログ記事も参考になります。

[私のドメイン] のエンティティ ID を設定している場合、SP が開始するログインはディープリンクに対応しています。Salesforce 内の深い階層からのリンクをブックマークして、ログアウトしてください。ブラウザーを再読み込みして、そのブックマークを選択します。IdP にリダイレクトされ、認証されて、ブックマークしたリンクに再度リダイレクトされます。

よくある問題とトラブルシューティング

• 統合 ID の大文字と小文字が正しくない。

  統合 ID が組織のメールアドレスである場合、AD FS が送信するとおりに入力してください。そうしないと、Salesforce は一致するユーザーを検出できません。

  要求の言語では、基本的な正規表現の置換しか行われないため、LDAP 属性を送信する前に大文字と小文字を正規化するカスタム要求ルールを記述することはできません。

• アサーションの期限が切れた。

  タイムスタンプから 5 分を経過したアサーションは拒否されます。

  

  メモ Salesforce では 3 分間のクロックスキューが許容されます。そのため、アサーションの有効期間は、タイムスタンプの 3 分前から 8 分後まで許容されます。また、アサーションは、有効期間 (5 分未満に設定可能) で指定されたとおりに期限切れになります。

  Network Time Protocol (NTP) を使用して、AD FS サーバーのシステムクロックが正しいインターネット時刻ソースと同期するようにしてください。

• Salesforce にログインできない。

  エラーにより、SSO を介して Salesforce にログインできない場合でも、ユーザー名とパスワードを使用してログインできます。ログイン URL に「?login」を付加します (例: https://login.salesforce.com/?login)。ログイン後、この問題のトラブルシューティング中は必要に応じて SSO を無効にできます。