［運用］
Windowsで構築する、クラウド・サービスと社内システムのSSO環境 第3回

2．Google AppsとAD FS 2.0との連携

Microsoft MVP
Identity Lifecycle Manager
伊藤忠テクノソリューションズ株式会社
富士榮 尚寛
2010/09/22

[SaaS]Google Appsとの認証連携

　ここでは、Google AppsとAD FS 2.0との連携を設定する。そのために利用するGoogle Appsのシングル・サインオン機能は、PremierエディションおよびEducationエディションで提供されている（無料のStandardエディションでは利用できないので注意）。

　なお、以下のページにGoogle Appsのシングル・サインオン機能が対応している仕様などの詳細が解説されているので、一読しておく。

　実現する環境は下記のとおりだ。

Google Appsへのシングル・サインオン環境

　なお、以下の設定前にあらかじめGoogle Apps側のアカウントは別途作成しておく必要がある。これを自動化するにはGoogle AppsのProvisioning APIに対応した製品（CA Identity ManagerやExgen Networks LDAP Managerなど）を使って実装する必要がある。また、マイクロソフトのForefront Identity Manager 2010については、筆者が作成したGoogle Apps対応エージェントを以下のブログ記事で解説しているので参照していただきたい。

　では、実際に設定をしていく。

■Google Apps側の設定
　まず、Google Appsコントロール・パネルの「高度なツール」メニューの中の「シングル サインオン (SSO) の設定ページ」にアクセスする。

Google Apps側のシングル・サインオン設定画面

　ここでは、Google Appsへのログオン認証システムとして社内のAD FS 2.0を指定するための設定を行う。

設定項目 設定値 備考
シングル サインオンを有効にする 有効（チェックを入れる）  
ログイン ページのURL https://＜AD FS 2.0サーバ＞/adfs/ls AD FS 2.0のトークン発行エンドポイント
証明書の確認 CN=ADFS Signing − ＜AD FS 2.0サーバ＞ AD FS 2.0のトークン署名に使用している証明書（自動生成）をエクスポートする
ドメイン固有の発行元を使用 有効（チェックを入れる）  
Google Apps側の設定項目
※パスワード変更URLをイントラネットのライフサイクル管理システムのパスワード変更URLにしておくことで、Active Directoryのパスワード変更との連動も可能だ（先の画面ショットのURLはダミーである）。

　前回の解説のとおり認証要求元（リライング・パーティ： RP）とIdPの間で直接の通信はないので、Google AppsからAD FS 2.0のサーバに対して名前解決やアクセスができる必要はない（上記画面の例でも「myidp.local」というローカルなドメイン名を使っている）。

■AD FS 2.0側の設定
　次はIdPとなるAD FS 2.0側の設定である。ここでは認証要求元（RP）としてGoogle Appsを信頼するという設定を行う。

　AD FS 2.0の管理コンソールのトップ・ページに表示される［必須: 信頼できる証明書利用者を追加する］リンクをクリックすると構成ウィザードが開始されるので、下記の表に基づいて設定を行う。

AD FS 2.0の管理コンソール

設定項目 設定値
証明書利用者についてのデータ取得方法 ［証明書利用者についてのデータを手動で入力する］を選択
表示名 Google Apps（任意）
プロファイルの選択 ［AD FS 2.0プロファイル］を選択
URLの構成 ［SAML 2.0 WebSSOプロトコルのサポートを有効にする］にチェックを入れる
証明書利用者SAML2.0 SSOサービスのURL https://www.google.com/a/＜GoogleAppsのドメイン名＞/acs
証明書利用者信頼の識別子 google.com/a/＜GoogleAppsのドメイン名＞
発行承認規則の選択 ［すべてのユーザーに対してこの証明書利用者へのアクセスを許可する］を選択
証明書利用者信頼（RP）の追加ウィザードにおける設定項目

　ウィザードが完了したら、次は要求規則の追加を行う。これはデータ・ソースとなるActive Directoryの属性をRPへ渡すクレームへマッピングする作業で、「発行変換規則」と呼ばれる要求規則を次のように追加する。

要求規則（発行変換規則）の追加ウィザードにおける設定
これは「変換要求規則の追加」ウィザード画面の2ステップ目。前述の構成ウィザードが完了すると自動的に要求規則の編集ダイアログが表示される。そこで［発行変換規則］タブにある［規則の追加］ボタンをクリックすると、このウィザードが起動するので、下表のように各項目を設定して要求規則を完成させる。
ウィザードの最初のステップ。ここでは［要求規則テンプレート］にて［LDAP属性を要求として送信］を選択して次へ進む。
この規則の名前（任意）を入力する。ここでは「Google Apps」とした。
［Active Directory］を選択する。
「E-Mail-Addresses」と入力する。に移るには［Tab］キーを押す。
「名前 ID」と入力する。

　要求規則の中で属性ストアのLDAP属性「E-Mail-Addresses」を「名前ID」にマッピングするという設定を行ったので、マッピング元となるActive Directoryユーザーの電子メール属性にGoogle AppsのログインIDとなるメール・アドレスを設定する。

Active Directoryのユーザー属性の設定
「Active Directory ユーザーとコンピュータ」で対象のユーザー・アカウントのプロパティを開いて設定する。
このタブを選ぶ。
Google AppsのログインID（メール・アドレス）を入力する。

　Active Directoryのユーザー属性がGoogle Appsとどのように関連するのか図解すると下記のようになる。

Active Directory属性とGoogle AppsのログインIDのマッピング

■Google Apps連携の実際の動作
　ここまで設定ができたら実際にGoogle Appsのサービスにアクセスしてみる。ここではGmailを使ってみる。

　「https://mail.google.com/a/＜ドメイン名＞」へアクセスするとIdPであるAD FS 2.0でWindows統合認証が行われ、そのときPCにログオンしているユーザーのメール・アドレス属性の値（メール・アドレス）でそのままGmailへログオンできるはずだ。

Gmailへのシングル・サインオン


　INDEX
　 ［運用］Windowsで構築する、クラウド・サービスと社内システムのSSO環境
　 第1回　クラウド・コンピューティングとアイデンティティ管理の概要
　   1．クラウド・コンピューティングの基礎と課題
　   2．クラウドでのセキュリティ対策とアイデンティティ管理の役割
　   3．クラウドがアイデンティティ管理システムにもたらす変化
　
　 第2回　クラウド・コンピューティング時代の認証技術
　   1．アイデンティティ連携（フェデレーション）の要素技術
　   2．マイクロソフトのアイデンティティに関するビジョン
　   3．アイデンティティ・メタシステムの実装
　
　 第3回　クラウド・サービスと社内ADとのSSOを実現する（前）
　   1．AD FS 2.0のセットアップ
  2．Google AppsとAD FS 2.0との連携
　   3．Windows Live IDとAD FS 2.0との連携
　   4．Salesforce.com CRMとAD FS 2.0との連携
　
　 第4回　クラウド・サービスと社内ADとのSSOを実現する（後）
　   1．Windows AzureとAD FS 2.0との連携（1）
　   2．Windows AzureとAD FS 2.0との連携（2）

　Windows 運用


Windows Server Insider フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間
＠IT