Uncategorized

Azure AD (Entra ID) の Google Apps 連携 – App Access Enhancements

By on • ( 3 Comments )

開発者にとっての Azure Active Directory (Microsoft Entra ID)

こんにちは。

先日 (水曜) の Azure セミナーにご参加いただいた皆様、お疲れ様でした。今回は、完成版の動きでご紹介した Application Access Enhancements についてです。

皆さんの会社でも動かしていただけるように、デモでお見せした Google Apps を例に SAML-P でフェデレーションする方法を以下に補足しておきます。(注意点も含め)

 

Azure AD の Application Access Enhancements

「Azure Active Directory とは (事前準備)」で解説したように、Azure Acitve Directory では、WS-Federation や SAML-P に対応した Application (SaaS) のフェデレーションが可能です。相手側の作りにもよりますが、Azure Acitve Directory にログイン (サインイン) して、SAML に対応した他社のサービス (例えば、今回紹介する Google Apps など) を使用するシナリオが実現できます。
Application Access Enhancements は、こうした既存の SaaS アプリとのフェデレーションをウィザード・ベースでより簡単に実現するために Azure Acitve Directory に追加されたサービスです。(といっても、もう登場してかなり時間が経ってますが…)

と、大きなコンセプトを書きましたが、実際には、「TechNet : Application access enhancements for Windows Azure AD」に書かれているように、この Application Access Enhancements には以下の 2 つのフェデレーション方法が提供されており、現状では、仕組み上、前者のフェデレーションが幅広いアプリケーションに対応しています。 (上記で私が記載した方法は、むしろ後者のほうです。)

  • Password-based single sign-on
    Plug-in (extension) をブラウザーにインストールすることで、パスワードなどの入力を自動化し、シングル・サインオン (SSO) をおこなう方法です。Azure AD は各ユーザーの情報を SaaS アプリにセットアップし、パスワードは Azure AD 側で一括で管理します。(なお、Azure AD は、SaaS アプリケーションに専用のパスワードでログインします。)
    この方法については、「Azure AD で フェデレーション未対応の Web アプリと SSO を構成する (Password-based Single Sign-On)」に解説しましたので参照してください。
  • Federation-based single sign-on
    いわゆる SAML などの標準プロトコルを使ってフェデレーションをおこなう方法です。Plug-in のインストールも不要です。
    この投稿では、この方法について解説します。

上記の通り、そもそも連携の概念が双方で異なっている点に注意してください。前者はどちらかというと ID を Azure AD 側で一元化して SaaS アプリに配布するような連携のイメージです。(後者は、一般的なフェデレーションの概念です。)

また、この仕組みからわかるように、Password-based SSO では環境に大きく依存します。例えば、Plug-in に対応していない IE や Chrome 以外のブラウザー (Safari など) では使用できません。一方、Federation-based SSO は標準的なブラウザー ベースのフェデレーション (HTML, CSS, JavaScript を使った実装) なので、こうした制約を受けません。

その一方、Federation-based SSO は、最低限、接続先の SaaS 側が対応されている必要があり (かつ、現時点では、Azure AD 側も、WS-Fed, SAML-P や、一部の OpenID しか対応していないので)、接続可能な SaaS が限定されます。これに対し、Password-based SSO のほうは、ほぼすべての SaaS で使用可能です。
現在では、Google Apps, Salesforce など、主要な 50 以上の SaaS アプリケーションが Federation based SSO に対応しています。

今回は、デモでお見せした Google Apps の Federation-based SSO を例に紹介します。

 

Overview step

2015/11 追記 : Google 側の設定 (Configuration) は不要になりました。(Google 側の必要な Configuration は、Azure AD 側から Google の API を通して自動でおこなわれます。)

全体の流れとしては、以下の通りセットアップします。

  1. Single Sign-On (SSO) のための構成をおこないます (エンドポイントの登録、証明書のアップロード、など)
  2. Azure AD に登録されたユーザーを Google Apps (SaaS) に同期させるため設定をおこないます
  3. Azure AD 側で Google Apps を使用できるユーザーを選択して同期させます

なお、Single Sign-On (SSO) の構成だけをおこなってユーザー同期をしないといった構成は不可能です。(すべて設定する必要があるので注意してください。)

では、この 3 つのステップを以下に解説します。

 

まずは、Domain の準備

まず当然ですが、Azure Management Portal (管理ポータル) にログインして Azure Active Directory のテナントを新規作成してください。(この手順は省略します。)

そして構成をはじめる前に、作成した Azure AD のテナントのドメインと、Google Apps のテナントのドメインを揃えておく必要があるので注意してください。(Google Apps for Business を使用する際にドメインを作成されていると思いますので、そのドメインを使用すれば十分です。)

Azure Active Directory 側のドメイン設定は簡単です。

まず、Azure Management Portal で作成した Azure Active Directory テナントの [ドメイン] (Domain) タブをクリックし、[カスタム ドメインの追加] のリンクをクリックします。
表示される画面にドメイン名を入力して、[追加] ボタンを押します

つぎの画面 (ウィザード) では、Azure Active Directory がこのドメインを確認するために必要なホスト レコードの情報画面が表示されます。この画面に記載されている内容をお使いのレジストラーに登録してから、[確認] ボタンをクリックして次に進みます。

ドメインが設定できたら、さいごに、作成したドメインを選択して [プライマリーの変更] (Change primary) ボタンをクリックし、プライマリー ドメインに設定しておきます。

Google Apps 側も同様にドメインの設定が必要ですが、この設定方法については省略します。(Google のドキュメントを参照してください。)

 

Google 側での API 利用の許可

まずは、以下の手順で Google Apps 側で API アクセスを有効にしておきます。

  • Google Apps の管理コンソールを開き、[その他の設定] をクリックして、再度、[セキュリティ] (Security) をクリックします。
    今度は、[API リファレンス] (API reference) というリンクをクリックします。
  • 右に表示されるペインで、[API アクセスを有効にする] (Enable API access) をチェックして保存します。

 

SAML による Single Sign-On (SSO) のための構成

では、Google Apps (SaaS) とのフェデレーションを構成していきましょう。

作成した Azure AD のテナントを選択して、[アプリケーション] (Applications) タブを選択します。
表示される画面で [追加] ボタンを押すと、[組織で開発中のアプリケーションを追加] (Add an application my organization is developing)、[組織で使用するアプリケーションを追加] (Add an application for my organizatio to use) の選択画面が表示されるので、ここで [組織で使用するアプリケーションを追加] (Add an application for my organizatio to use) をクリックします。

すると、下図の画面が表示されるので、ここで Google Apps を選択して追加します。

つぎに、ウィザードが表示されます。(このウィザードは、あとからゆっくり設定していただいても結構です。)

まずは、[シングル サインオンの構成] (Configure single sign-on) をクリックします。

すると、下図の通り、シングル サインオンのモードを選択する画面が表示されるので、ここで、上の [ユーザーは Azure AD のアカウントを使用して認証] (Users authenticate with their account in Windows Azure AD) を選択することで Federation-based SSO の構成が開始されます。

つぎのウィザードに進むと、Google Apps Tenent Url を入力する画面が表示されるので、「https://www.google.com/a/<domain>」 (例 : https://www.google.com/a/tsmatsuz.com) を入力します。

2015/11 追記 : 以降の、Google 側の設定 (Configuration) は不要になりました。(Google 側の必要な Configuration は、Azure AD 側から Google の API を通して自動でおこなわれます。)

つぎに表示されるウィザードでは、Google Apps 側に設定すべき項目の情報が表示されます。ここに記載されている証明書をダウンロードし、表示されている URL 文字列をメモ帳などにコピーしておきます。

そして、上記の情報を使って、Google Apps の管理コンソール (Admin console, URL は後述の「注記」を参照) で設定をおこないます。
まず、Google Apps に管理者でログインし、Google Apps の管理コンソール (Admin console) を表示します。表示される管理コンソールで、[その他の設定] をクリックして [セキュリティ] (Security) のリンクをクリックし、[詳細設定] (Advanced settings) をクリック、[シングル サインオン (SSO) の設定] (Set up single sign-on) をクリックすると、下図の画面が表示されるので、ここに以下の通り設定をおこないます。

なお、現時点では、この際に重要な注意事項がありますので、下記の注記を参照してください。

  • [シングル サインオンを有効にする] (Enable Single Sign-on) をチェック (選択) します
  • [ログイン ページの URL] (Sign-in page URL) に上記 (Azure AD) でコピーした URL を設定します
  • [ログアウト ページ URL] (Sign-out page URL) に上記 (Azure AD) でコピーした URL を設定します
  • [パスワード変更 URL] (Change password URL) に上記 (Azure AD) でコピーした URL を設定します
  • [ドメイン固有の発行元を使用] (Use a domain specific issuer) にチェックを入れます (2014/09 追記 : 後述の「補足事項」に記載した App Access Panel を使用しないフェデレーションのために必要です)
  • [認証の確認] (Verification certification) 上記 (Azure AD) でダウンロードした証明書をアップロードします (ただし、現時点では、下記の注記を参照)

注記 : なお、以降、Google Apps 側の管理をおこなう際は、シングル・サインオン (SSO) が有効になっているため、例えば、下記の URL などを使用して特権管理者でログインしてください。(SSO により、ログインが Azure AD にリダイレクトされてしまいます。)

https://www.google.com/a/<domain>/ServiceLogin?service=CPanel&passive=1209600&continue=https://admin.google.com

 

ユーザー同期の設定

つぎに、Azure AD のユーザーを Google Apps と同期させます。
この同期設定をおこなうと、Azure AD 上で Google Apps のユーザーとして指定したユーザー情報が Google Apps にも登録され、以降、このユーザーは同期対象となります。

  • 今度は Azure Management Portal で、作成した Azure Active Directory テナントの [アプリケーション] (Applications) タブをクリックして、登録されている Google Apps (上記で SSO を構成したアプリケーション) をクリックします。
  • 表示された画面で、今度は [ユーザー プロビジョニングの構成] (Configure user provisioning) を選択します。
  • 表示された画面に、Google Apps (皆さんのテナント) のドメイン名、管理者アカウント、パスワードを入力し、次に進んで完了します。

 

Google Apps を使用できるユーザーを設定 (同期の開始)

さいごに、Google Apps を使用できるユーザーを選択します。(なお、実際の運用では、個別のユーザーではなくグループを作成して Google Apps に割り当てることも可能です。「TechNet : Azure Active Directory Premium」を参照してください。)

まず、普通に、Azure Management Portal で Azure Active Directory のこのテナントにユーザーを追加しておきます。(この際、ID のドメインとして、上記で構成したものを使用します。)

再度、Azure Active Directory テナントの [アプリケーション] (Applications) タブをクリックして、登録されている Google Apps (上記で構成したアプリケーション) をクリックします。
表示される画面で、今度は [ユーザーの割り当て] (Assign users) を選択します。

表示される画面で、ユーザーを選択し、下部の [割り当て] (Assign) ボタンを押すと同期が開始されます。

なお、この設定をおこなうと、初回のログインなどに、下記の通りユーザーが Google Apps 側に登録されるのが確認できます。

 

動作の確認

では、動作を確認してみましょう。

GMail などに直接 アクセスした場合でも、Azure AD のログイン画面にリダイレクトされてログイン可能ですが、今回は、Azure AD の Application Access Panel から Google Apps にアクセスしてみます。

ブラウザーをいったんすべて閉じ、ブラウザーを開いて下記の Application Access Panel の URL にアクセスします。
Azure Active Directory のいつものログイン画面が表示されるので、Azure AD のユーザー ID / パスワードを入力してログインします。(上記で有効にしたユーザーでログインします。)

https://account.activedirectory.windowsazure.com/applications

ログインに成功すると、下図のようなクラウド・アプリケーション (SaaS) の選択画面が表示されます。(ここは、まだ Azure AD が表示しています。)

上記で Google Apps を選択すると、Google Apps にアクセスされて、初回利用時には下記の画面が表示されます。[同意します] (Permit) をクリックすることで GMail などの各種サービスを使用することができます。

 

補足事項

2014/09 更新 : 下記の問題は改善されました。GMail などに直接 アクセスした場合でも、Azure AD のログイン画面にリダイレクトされてログイン可能です。
この更新 (改善) については「Active Directory Team Blog : 50+ SaaS Apps and growing now support federation with Azure AD!」を参照してください。(みなさんのフィードバックのおかげです。たくさんのフィードバック、ありがとうございました !)

なお、GMail 等の Google Apps のサービスに直接アクセスした場合にも Azure AD にリダイレクトされるのですが、残念ながら、Azure AD 側で Relying Party の不一致のエラーが発生します。理由は、Google Apps が SAML に含める Issuer (発行元) として「google.com」または「google.com/a/<domain>」が使用されるのですが、これが Azure AD に登録されている ServicePrincipalName と一致しないためです。(「Windows Azure Active Directory とは (事前準備)」に記載した通り、Windows PowerShell を使って画面で作成された ServicePrincipal の変更はできません。)

また、ここで紹介している App Access Enhancement を使用せず、Windows PowerShell を使って自前で Google Apps とのフェデレーションを構成することで回避できますが、今度は、Google Apps 側が NameIDPolicy として urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified を Request するのに対し、Azure AD が emailAddress とは別のフォーマットの NameID (一意の文字列の羅列) を返すので、ユーザーが不一致となり Google Apps 側でエラーになります。

このため、現状では、必ず上記の Application Access Panel 経由で接続する必要があり、GMail をブラウザーの「お気に入り」に直接登録した際のフェデレーションや、Mobile 用の GMail クライアントとの連携などは むずかしいです。
今後、こうした細かな設定が整ってくると良いですね。。。(皆様からのフィードバックを、お待ちしてます！)

なお、iOS から Application Access Panel を使用する場合は、「My Apps」という専用の Azure AD 用のアプリケーションも提供されています。iPhone などを使用されている方は、Apple App Store から導入 (インストール) してみてください。

Categories: Uncategorized

Tagged as: , ,

3 replies»

  1. Pingback: Azure Active Directory の SSO 開発 (Node.js 編) – tsmatz
  2. Pingback: Azure Active Directory の SSO 開発 (PHP 編) – tsmatz
  3. Pingback: Azure AD で フェデレーション未対応の Web アプリと SSO を構成する (Password-based Single Sign-On) – tsmatz

Leave a Reply