Shibboleth 2 による Microsoft Office 365 シングル サインオン (SSO)

Microsoft France

発行: 2012 年 10 月

バージョン: 1.0

作成者: Jean-Marie Thia (CNRS)、Philippe Beraud (Microsoft France)

寄稿者: Arnaud Jumelet (Microsoft France)、Philippe Maurent (Microsoft Corporation)

著作権情報

© 2012 Microsoft Corporation. All rights reserved.

概要

SAML 2.0 プロトコルのサポートを通じて、Internet2 Shibboleth 2 は、Microsoft Office 365 サービスとその Web アプリケーションおよび電子メール リッチ クライアント アプリケーション (Outlook など) とのクレーム ベースの (Web) シングル サインオン (ID フェデレーションとも呼ばれます) を提供します。

既存のドキュメントを基に作成された本書は、Windows Azure Active Directory および Office 365 のサービスに関するさまざまなシングル サインオン展開オプション、社内資格情報と Shibboleth 2 ID プロバイダーを使用して Windows Azure Active Directory および Office 365 のサービスへのシングル サインオンを有効にする方法、ならびにこのような展開のために知っておくべきさまざまな構成要素についての理解を深めることを目的としています。

本書は、Shibboleth 2 による Windows Azure Active Directory/Office 365 のシングル サインオン機能の基本事項、およびこのようなシステムの自社環境での計画と展開に関心があるシステム アーキテクトおよび IT プロフェッショナルを対象としています。

Shibboleth 2 による Microsoft Office 365 シングル サインオン (SSO)ii

本書は "現状有姿" のまま提供されます。このドキュメントに記載されている情報および見解は、URL およびその他の Web サイト参照先を含め、事前の通知なく変更されることがあります。本書の利用に関する責任はお客様が負うものとします。

本書で使用している例は説明を目的として提供されており、架空のものです。実在のものとは一切関係ありません。

本書は、マイクロソフト製品の知的財産権に関する法的権利をお客様に許諾するものではありません。本書は、内部における参照を目的として複製および使用することができます。本書は、内部における参照を目的として変更することができます。

© 2012 Microsoft Corporation. All rights reserved.

Microsoft、Active Directory、Internet Explorer、SQL Server、Windows、Windows PowerShell,、および Windows Server は、米国 Microsoft およびその関連会社の商標です。その他のすべての商標は、各社によって所有されています。

目次

1はじめに1

1.1本書の目的2

1.2本書の目的ではないこと6

1.3本書の構成8

1.4本書の対象者8

1.5本書で使用される用語8

2Shibboleth 2 の概要10

2.1SAML 2.0 標準の紹介12

2.2Shibboleth システム コンポーネントの論理アーキテクチャ15

2.3相互作用の原則と関連プロファイル18

2.4フェデレーション メタデータの定義19

3Windows Azure AD/Office 365 でのフェデレーション認証21

3.1フェデレーション ID のサインイン エクスペリエンス22

3.2フェデレーション ID の認証の種類23

4SSO 構成および関連する考慮事項について25

4.1シングル サインオンの準備25

4.2Shibboleth 2 ID プロバイダーの計画と展開26

4.3シングル サインオンで使用する Shibboleth の構成64

4.4Shibboleth 2 によるシングル サインオンに必要な Windows PowerShell のインストール70

4.5Shibboleth と Windows Azure AD の信頼関係の設定75

4.6ディレクトリ同期のセットアップ81

4.7Shibboleth 2 によるシングル サインオンの確認83

4.8Shibboleth 2 によるシングル サインオンのトラブルシューティング90

5フェデレーション認証が Office 365 と連動するしくみ91

5.1Shibboleth 2 の構成について91

5.2パッシブ/Web プロファイル認証フローについて96

5.3ECP – プロキシ認証プロファイル認証フローについて98

付録 A.Shibboleth 2 の用語と概念100

付録 B.Shibboleth 2 構成ファイルのサンプル102

Shibboleth 2 による Microsoft Office 365 シングル サインオン (SSO)i

はじめに

Microsoft Office 365[footnoteRef:1] は、電子メール、共有予定表、インスタント メッセージング (IM)、ビデオ会議、およびドキュメント共同作業に対する、場所に縛られない安全なアクセスを提供します。 [1: Microsoft Office 365: http://www.microsoft.com/ja-jp/office365/online-software.aspx]

あらゆる規模の企業を対象に、マイクロソフトのコミュニケーション製品および共同作業支援製品のクラウド バージョンをデスクトップ スイートの最新バージョンに統合しました。Office 365 には次のものが含まれています。

· Microsoft Office: Microsoft Office Professional Plus 2010 は、Microsoft Office Web Apps とシームレスに接続し、PC、モバイル デバイス、およびブラウザーにわたって生産性を実現します。

注:

適切なデバイス、インターネット接続、およびサポートされているブラウザーが必要です。一部のモバイル機能では、Office 2010 アプリケーション、スイート、または Office Web Apps に含まれていない Office Mobile 2010 が必要です。さらに、Office Web Apps、Office Mobile 2010、および Office 2010 アプリケーションの機能には、いくつかの違いがあります。

· Microsoft Exchange Online: Exchange Online は、クラウド ベースの電子メール、予定表、連絡先に対して、最新のウイルス対策およびスパム対策ソリューションを提供します。事実上あらゆるモバイル デバイスの電子メールにアクセスして、ボイス メール、ユニファイド メッセージング、およびアーカイブのためのオプションを利用できます。

· Microsoft SharePoint Online: SharePoint Online は、エンタープライズ ソーシャル ネットワーキングとカスタマイズによって、同僚、パートナー、および顧客を接続するサイトを作成するためのクラウド ベースのサービスです。

· Microsoft Lync Online: Lync Online は、画面共有、音声会議、ビデオ会議によって、クラウド ベースの IM、プレゼンス、およびオンライン会議の操作環境を提供します。

注:

本書に記載されていない Office 365 の詳細情報については、製品のオンライン ドキュメント[footnoteRef:2]、Office 365 for Enterprise 展開ガイド[footnoteRef:3]、Office 365 TechCenter Web サイト[footnoteRef:4]、および Office 365 Community Web サイト (ブログ、フォーラム、Wiki など.)[footnoteRef:5]を参照してください。 [2: Office 365 ヘルプ: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/] [3: Office 365 for Enterprises 展開ガイド: http://www.microsoft.com/ja-jp/download/details.aspx?id=26509] [4: Office 365 TechCenter Web サイト: http://technet.microsoft.com/ja-jp/office365/default] [5: Office 365 コミュニティ Web サイト: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/]

SharePoint Online で作成された匿名アクセス用のインターネット サイトの場合を除き、Office 365 サービスにアクセスするにはユーザーの認証が必要になります。

本書の目的

Microsoft Office 365 に初めてサインアップするときに、組織に関する詳細情報の提供と組織のインターネット ドメイン名の登録を求められます。

この情報は、その後、Windows Azure Active Directory[footnoteRef:6] (Windows Azure AD) で組織用の新しいテナントを作成するために使用されます。 [6: Windows Azure Active Directory: http://technet.microsoft.com/ja-jp/library/hh967619.aspx]

注:

組織ドメインおよびユーザー アカウントは、このページ[footnoteRef:7] を使用して、Office 365 にサインアップせずに作成できます。 [7: Windows Azure Active Directory サインアップ: https://activedirectory.windowsazure.com/Signup/QuickSignup.aspx?ru=https://activedirectory.windowsazure.com/default.aspx&culture=ja-jp&ali=1]

Windows Azure AD は、ディレクトリ データと ID サービスのコア セット (ユーザー ログオン プロセス、認証、フェデレーション サービスを含む) のためのクラウド ベースのストアです。Office 365 は、サブスクリプションの ID 管理にこれらの機能を使用します。

注:

マイクロソフトは、多様な組織およびニーズに対応できるように、さまざまな Office 365 プランを用意しています。一部のプランはシングル サインオン (SSO) 機能をサポートしていませんので、ご注意ください。この機能は、エンタープライズ プランではすべてサポートされます。本書では、E3 プラン サブスクリプションを用いてこの機能について説明します。

興味深いことに、Office 365 に登録する組織は、Windows Azure AD を使用して SSO を構成し、既存の自社運用の ID 管理環境との相互運用性を確保できます。これを構成するには、マイクロソフト オンライン ポータル (MOP) または Windows Azure AD 管理ポータル[footnoteRef:8](プレビュー版) のいずれかを使用します。 [8: Windows Azure AD 管理ポータルのプレビュー版: https://activedirectory.windowsazure.com/]

注:

この 2 つのポータルはいずれも、組織のテナントに関連付けられている Windows Azure AD の単一の共有インスタンスとの間で読み書きを行います。このように、これらのポータルは、テナント データの取得や変更を行うフロントエンド インターフェイスとして機能します。Windows Azure AD ポータルでほとんどの機能を実行することができます。また、組織が登録したすべてのクラウド サービスに関連付けられているユーザー、グループ、ドメイン、ライセンスをすべて 1 か所で確認できるという利点もあります。

Windows Azure AD 組織のテナントの SSO 機能を活用することにより、Office 365 では自社運用の ID インフラストラクチャ (Active Directory、LDAP など) に対する認証を行えるため、ユーザーは社内資格情報を使用して、プロビジョニング対象の Office 365 のサービスにアクセスすることができます。

このため、内部の企業ネットワーク上のユーザーまたは VPN を通じて接続されているユーザーは、Office 365 のサービスにシームレスにアクセスできます。ユーザーが自宅のコンピューターまたは企業ネットワークに接続されていないコンピューターから Office 365 のサービスにアクセスする場合も、社内資格情報を使用して Office 365 のサービスにアクセスできます。

このようなユーザー サインインのエクスペリエンスは、多くの組織が待ち望んでいるものです。

· 企業ネットワーク上の作業用コンピューター: 作業中のユーザーが企業ネットワークにサインインしている場合には、SSO によって Office 365 のサービスにアクセスできます (この機能を維持するために使用されている自社運用のセキュリティ トークン サービス (STS) によっては、再度サインインせずにアクセスできます)。

· 自宅または公共のコンピューター: ユーザーは、Office 365 のサービスにアクセスするには、社内資格情報を使用してサインインする必要があります。それでも、社内でのアクセスと Office 365 へのアクセスのために資格情報のセットを 1 つだけ覚えておけば済むため、便利です。

· スマートフォン: スマートフォンでは、Microsoft Exchange ActiveSync (EAS) を使用して Microsoft Eｘchange Online にアクセスするには、ユーザーは社内資格情報を使用してサインインする必要があります。それでも、社内でのアクセスと Office 365 へのアクセスのために資格情報のセットを 1 つだけ覚えておけば済むため、便利です。

· Microsoft Outlook その他の電子メール クライアント: ユーザーは、Outlook や、IMAP または POP クライアントなどの Office に含まれない電子メール クライアントを使用している場合、電子メール メッセージにアクセスするには社内資格情報を使用してサインインする必要があります。

注:

Windows Azure AD テナントへのサインアップは 1 回だけ必要です。その後、Windows Intune[footnoteRef:9] などの他のマイクロソフト クラウド サービスに登録する場合は、その同じテナントにサインインできます。組織の Windows Azure AD テナントをこのように使用することによって、将来登録する可能性がある追加サービスでも、既に構成済みの既存のユーザー アカウント、ポリシー、設定または自社運用サーバー展開をフルに活用して、組織の自社運用の ID インフラストラクチャと Windows Azure AD の間の効率を向上させることができます。 [9: Windows Intune: http://technet.microsoft.com/ja-jp/windows/intune.aspx]

たとえば、もともと Office 365 サブスクリプションにサインアップしていて、ディレクトリ同期やシングル サインオンを構成することによって自社運用の ID インフラストラクチャと Windows Azure AD テナントをさらに統合するための手順を既に経ていた場合は、後で Windows Intune などの別のマイクロソフト クラウド サービスにサインアップし、Office 365 とまったく同じディレクトリ統合のメリットを活用することができます。

本書の執筆時点では、Windows Azure AD の SSO 機能の STS に関する主なオプションは、組織が自社運用環境に展開して、安全に通信するように Windows Azure AD を構成するための、Active Directory フェデレーション サービス (AD FS) 2.0 サービスです。

AD FS 2.0 は Windows (Server) プラットフォームのコンポーネントなので、使用権は関連するライセンス コストに含まれます。

重要:

Windows Server 2008 (R2) で利用可能な AD FS の役割は、AD FS 2.0 には対応していません。これは、以前のバージョンである 1.1 に対応しています。特定のオペレーティング システムのバージョン (Windows Server 2008 または Windows Server 2008 R2) 用の AD FS 2.0 ソフトウェア パッケージは、AdfsSetup.exe セットアップ ファイルです。このファイルをダウンロードするには、「Active Directory Federation Services 2.0 RTW - 日本語[footnoteRef:10]」にアクセスしてください。 [10: Active Directory Federation Services 2.0 RTW - 日本語: http://www.microsoft.com/ja-jp/download/details.aspx?id=10909]

重要:

本書の執筆時点で、AD FS 2.0 の更新プログラムのロールアップが提供されています。この更新プログラムのロールアップ (または以前のロールアップ[footnoteRef:11]) には、Office 365 のシングル サインオン機能に関して本書で説明している AD FS 2.0 RTW の修正プログラムおよび更新プログラムが含まれています。この更新プログラムのロールアップとそのダウンロードの詳細については、サポート技術情報の記事 2681584「Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0[footnoteRef:12]」(英語) を参照してください。 [11: サポート技術情報の記事 2607496「Active Directory フェデレーション サービス (AD FS) 2.0 の更新プログラムのロールアップ 1 について」: http://support.microsoft.com/kb/2607496] [12: サポート技術情報の記事 2681584「Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0」: http://support.microsoft.com/kb/2681584 (英語)]

AD FS 2.0 による Office 365 の SSO の計画と構成の詳細については、Microsoft ダウンロード センターにあるホワイト ペーパー「AD FS 2.0 による Office 365 シングル サインオン[footnoteRef:13]」を参照してください。 [13: AD FS 2.0 による Office 365 シングル サインオン: http://www.microsoft.com/ja-jp/download/details.aspx?id=28971]

本書は、AD FS 2.0 による Windows Azure AD および Office 365 のサービスのさまざまなシングル サインオン展開オプション、社内の Active Directory (AD) 資格情報と AD FS 2.0 を使用して Office 365 のサービスへのシングル サインオンを有効にする方法、ならびにこのような展開のために知っておくべきさまざまな構成要素についての理解を深めることを目的としています。

MSDN Channel 9 Web キャスト「Microsoft Office 365: ID およびアクセス ソリューション[footnoteRef:14]」など (英語)、この件に関する貴重なコンテンツを提供してくれたマイクロソフトの上級プログラム マネージャー Ross Adams に感謝の意を表します。 [14: Microsoft Office 365: ID およびアクセス ソリューション: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/OSP215 (英語)]

AD FS 2.0 に加えて、Shibboleth 2 (および Optimal IDM Virtual Identity Server Federation Services[footnoteRef:15]、PingFederate 6.10[footnoteRef:16]) などの他のクレーム/ID プロバイダーのサポートが追加されたので、組織は、既存の自社運用の ID インフラストラクチャが AD または AD 以外のディレクトリのいずれに基づくものであっても、その ID インフラストラクチャを Windows Azure AD および Microsoft Online Services (Office 365 など) とのシングル サインオンのために引き続き使用することができます。フェデレーション SSO インフラストラクチャを既に実装済みの組織では、それを Office 365 に再利用することをお勧めします。 [15: Optimal IDM Virtual Identity Server Federation Services: http://go.microsoft.com/fwlink/?LinkID=266318 (英語)] [16: PingFederate 6.10: http://go.microsoft.com/fwlink/?LinkID=266320 (英語)]

現在、Shibboleth 2 Identity Management システムは、世界中の多くの教育機関および研究機関によって特に活用されています。Shibboleth 2 は、ID リポジトリとして使用できるさまざまなデータ ソース (Active Directory、その他の LDAP ディレクトリ、SQL データベースなど) をサポートしています。

Shibboleth 2 は、組織境界を越えてまたは組織境界の内部で Web シングル サインオンを提供するための、標準の Security Assertion Markup Language (SAML) 2.0[footnoteRef:17] プロトコルを使用する ID プロバイダーの実装です。 [17: Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996 (英語)]

Shibboleth 2 は、マイクロソフトおよびマイクロソフト以外のフェデレーション ソリューションとのクロスドメイン (Web) SSO (ID フェデレーションとも呼ばれます) を提供します。

Wikipedia[footnoteRef:18] では、ID フェデレーションは次のように定義されています。 [18: Wikipedia の ID フェデレーションの定義: http://en.wikipedia.org/wiki/Federated_identity (英語)]

「フェデレーション ID、つまり ‘ID のフェデレーション’ とは、自律的なセキュリティ ドメイン間での ID 情報のポータビリティを可能にするためのテクノロジ、標準、およびユースケースのことです。ID フェデレーションの最終目標は、あるドメインのユーザーがシームレスに、余分なユーザー管理を必要としない形で、安全に別のドメインのデータやシステムにアクセスできるようにすることです」

既存の Internet2 ならびにマイクロソフトのドキュメントおよびサポート技術情報の記事を基に作成された本書では、Shibboleth 2 による Windows Azure AD のシングル サインオン機能 (ID フェデレーションとも呼ばれます) についてさらに説明します。

そのため、Shibboleth 2 テクノロジについて簡単に説明して主な概念、要件、コンポーネントを紹介するだけでなく、以下の内容についても説明します。

· Windows Azure AD のさまざまな ID オプション

· このコンテキストにおいての Windows Azure AD の ID アーキテクチャおよび機能

· Shibboleth 2 によるフェデレーション認証のさまざまな実装シナリオ

· フェデレーション認証が Shibboleth 2 と連動するしくみ

これらをベースとして、このコンテキストにおいて Shibboleth 2 が関与する Windows Azure AD およびマイクロソフト クラウド サービス プロジェクトをさらに容易に完了し、その結果、お客様がこれらのサービスが持つすべての可能性を実現できるようになります。

Shibboleth 2 のサポートの範囲を超えた、汎用的な SAML 2.0 サポートは提供されませんのでご注意ください。

本書の目的ではないこと

ディレクトリ同期ではシングル サインオンは必須ではありませんが (ただし、より高度なユーザー エクスペリエンスを提供します)、ディレクトリ同期はシングル サインオンの要件です。

したがって、自社運用の ID と組織の Windows Azure AD テナントの同期を維持するには、ディレクトリ同期を実装する必要があります。

このメリットの 1 つとして、自社運用の ID インフラストラクチャに付属する既存のツールを使用して、従来の方法で社内のユーザー アカウントを制御および管理できることが挙げられます。

この 1 つのツールにより、実際に自社運用環境と Windows Azure AD 環境との間のシームレスなユーザー管理が実現します。

Active Directory を使用する組織は、Microsoft Online Services ディレクトリ同期ツール (DirSync)[footnoteRef:19] を通じて、これを容易に実装できます。DirSync ツールを使用すると、サービス管理者は、Windows Azure AD、つまり Office 365 ユーザー、連絡先、およびグループを、単一の Active Directory フォレスト用の自社運用の Active Directory ドメイン サービス (AD DS) で行われた変更に応じて更新することができます。 [19: Microsoft Online Services ディレクトリ同期ツールをインストールおよびアップグレードする: http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff652545.aspx]

ディレクトリ同期は、Windows Azure AD にとって新しい機能ではありません。DirSync ツールは、Microsoft Forefront Identity Manager (FIM) 2010 上に構築されています。ディレクトリ同期の構成は、Windows Azure AD 環境向けに簡素化されています。懸念となるような手動構成は必要ありません。すべてがウィザードを介して構成されます。

DirSync ツールの最初のバージョンは、自社運用の Active Directory 単一フォレスト向けでした。ただし、多くのお客様は、さまざまな理由で、次のような複数の自社運用 Active Directory フォレストを運用しています。

· 複数のアカウント フォレスト: ユーザー アカウントは複数の Active Directory フォレストに存在します。

· アカウントおよびリソース フォレスト: Exchange 組織は通常、リソース フォレスト モデルでホストされます。

上記の内容を通じて、以下のシナリオも検討することができます。

· 複数のアカウント フォレスト、自社運用の Exchange はなし

· 単一のアカウント フォレスト、単一の Exchange リソース フォレスト

· 複数のアカウント フォレスト、単一の Exchange リソース フォレスト

マルチフォレスト トポロジは、現在、特定の前提条件を満たすお客様について、Windows Azure AD でサポートされ、複数のフォレストからの同期を可能にします。また、本書のコンテキストでは、複数の AD フォレストでのシングル サインオンをサポートします。

この目的のため、"単純な" マルチフォレスト構成をサポートするための新しいバージョンの DirSync ツールが間もなくリリースされます。

以下の表に分類されているように、"単純な" マルチフォレスト シナリオのみをサポートできます。

基準

単純

複雑

自社運用の AD フォレスト間でオブジェクトを移動しますか。

いいえ

はい

複数の自社運用の AD フォレストのオブジェクトを含むセキュリティ グループがありますか。

いいえ

はい

自社運用の AD フォレスト間で重複するオブジェクトがありますか。つまり、同じオブジェクトが複数のフォレストに存在しますか。または、ユーザー オブジェクトの属性サブセットがあるフォレストで管理されていて、別のサブセットが別のフォレストで管理されていますか。

いいえ

はい

Exchange リソース フォレストがありますか。または、Exchange ハイブリッド展開 (別名 "豊富な機能を備えた共存") を必要としていますか。

いいえ

はい

重要:

各自社運用 AD フォレスト内のユーザーは、異なるユーザー プリンシパル名 (UPN) サフィックスを必要とします。たとえば、フォレスト A では @forestA.com、フォレスト B では @forestB.com です。フォレスト間で共有される UPN 名前空間は、仕様によりサポートされません。つまり、複数の AD フォレストにわたるすべてのユーザーに対して単一の UPN 名前空間を提供することはできません。

上の表は、"単純な" マルチフォレスト DirSync ツールの制限事項の概要を示すものです。

· マルチフォレスト Exchange ハイブリッド展開機能はサポートされません。

· ユーザーの一部の属性がある AD フォレストで管理され、その他の属性が別のフォレストで管理されているようなシナリオはサポートされません (アカウント/リソース フォレスト モデルなど)。

· 自社運用のフォレスト間でのユーザーの移動はサポートされません。この場合、ユーザーはクラウドで削除されてから再作成されることになります。そのため、メールボックスが削除されます。

これらの制限事項の影響を受けるシナリオに対応するには、DirSync ツールではなく、"複雑な" マルチフォレスト Active Directory 環境でのディレクトリ同期を処理するための FIM 2010 および Windows Azure AD Connector (Management Agent) for FIM 2010 (以前の名称は Office 365 Connector for FIM 2010) が必要になります。Windows Azure AD Connector for FIM 2010 を利用するには、現在、特定の前提条件を満たす必要があります。マイクロソフトに直接お問い合わせください。

本書の執筆時点では、Windows Azure AD Connector for FIM 2010 は、マイクロソフト プレミア デプロイメント (MPD) 経由でのみ提供されています。組織で "複雑な" マルチフォレスト サポートが必要な場合は、地域の Microsoft Office 365 CXP ソリューション アーキテクトまでお問い合わせください。

AD 以外のディレクトリを使用するまたは含む環境の場合は、FIM 2010 と Windows Azure AD Connector for FIM 2010 も必要になります。

マルチフォレスト サポートに関して、このソリューションを利用するには、現在、同じ前提条件を満たす必要があります。組織で AD 以外のディレクトリが必要な場合は、地域の Microsoft Office 365 CXP ソリューション アーキテクトまでお問い合わせください。

シングル サインオンを最初にインストールして構成してから、ディレクトリ同期を実装することをお勧めします。これは必須ではありませんが、推奨事項です。

本書では、ディレクトリ同期については詳しく説明しません。このトピックの詳細については、Windows Azure AD オンライン ドキュメントの「ディレクトリ同期を構成する[footnoteRef:20]」を参照してください。 [20: ディレクトリ同期を構成する: http://technet.microsoft.com/ja-jp/library/hh967629.aspx]

本書の構成

前記の目的に対応するため、本書は、取り上げるテーマごとに以下のセクションに編成されています。

· Shibboleth 2 の概要

· Windows Azure AD/Office 365 でのフェデレーション認証

· SSO 構成および関連する考慮事項について

· フェデレーション認証が Office 365 と連動するしくみ

本書の対象者

(クロスドメイン) SSO (ID フェデレーションとも呼ばれます) は、通常は多くの側面を含む広範なトピックであり、プロトコル、標準、トークン等について深い理解が必要です。本書では、Windows Azure AD/Office 365 の観点からのみ、概念レベルと技術レベルの両方で SSO トピックについて説明します。

本書の執筆時点では、既に説明したとおり、AD FS 2.0、Shibboleth 2、Optimal IDM Virtual Identity Server Federation Services、および PingFederate 6.10 のみが、この機能を有効にするためにサポートされるテクノロジです (この機能が将来的に進化する可能性がある場合でも)。

本書は、Shibboleth 2 によって Windows Azure AD のこの SSO 機能を有効にし、Office 365 のサービスにシームレスにアクセスするように構成する方法を理解したいと考えているシステム アーキテクトおよび IT プロフェッショナルを対象としています。

前記のホワイト ペーパー「AD FS 2.0 による Office 365 シングル サインオン」と目的はまったく同じですが、AD FS 2.0 ではなく Shibboleth 2 テクノロジを使用します。本書は、Office 365 の ID およびセキュリティ機能に関するドキュメント シリーズの一部です。

注:

Optimal IDM Virtual Identity Server Federation Services および PingFederate 6.10 ソリューションを ID プロバイダーとして活用してシングル サインオンを実装する方法の詳細については、オンライン ヘルプ トピック「 サードパーティの ID プロバイダーによるシングル サインオンを実装して管理する[footnoteRef:21]」を参照してください。Active Directory ユーザーにシングル サインオンを提供するように PingFederateソリューションを構成する方法については、「PingFederate を使用した Office 365 への Web SSO[footnoteRef:22]」を参照してください。 [21: サードパーティの ID プロバイダーによるシングル サインオンを実装して管理する: http://technet.microsoft.com/ja-jp/library/jj679342.aspx] [22: PingFederate を使用した Office 365 への Web SSO: http://go.microsoft.com/fwlink/?LinkID=266321]

本書で使用される用語

本書では、マイクロソフトと Internet2 の製品およびテクノロジでさまざまな名称で呼ばれているフェデレーションの概念を多数参照しています。次の表を使用すると、この 2 つを対応させることができます。

概念

マイクロソフトでの名称

Shibboleth での名称

ユーザーを処理しているフェデレーション パーティからアプリケーションを管理しているフェデレーション パーティへのアクセス要求中に送信されるユーザーを記述する XML ドキュメント

セキュリティ トークン

アサーション

ユーザーのためのセキュリティ トークンを作成する、フェデレーション内のパートナー

クレーム プロバイダー

ID プロバイダー (IdP)

アプリケーションへのアクセスを提供するためのトークンを使用する、フェデレーション内のパートナー

証明書利用者 (RP)

サービス プロバイダー (SP)

セキュリティ トークン内部で送信される、ユーザーに関するデータ

クレーム

アサーション属性

本書で、Shibboleth 2 ソフトウェアは、クレーム プロバイダー/ID プロバイダーの役割を実行し、Windows Azure AD は、クレーム プロバイダー/ID プロバイダーの役割と証明書利用者/サービス プロバイダーの役割の両方を実行し、Office 365 のサービスは、証明書利用者/サービス プロバイダーの役割を実行します。

Windows Azure AD は、Shibboleth 2 と Office 365 のサービスとの間のゲートウェイとして機能します。Windows Azure AD サインイン サービス (STS) は、相互運用性を最大限に高めるため、WS* プロトコルをサポートするだけでなく、Microsoft Federation Gateway (MFG) を拡張して SAML 2.0 プロトコルをサポートします。

Shibboleth 2 の概要

ここでは、Windows Azure AD/Office 365 を Shibboleth ID フェデレーションで公開する方法を簡単に理解できるように、テクノロジの観点と、SAML 2.0 によるプロトコルの観点から Shibboleth 2 システムについて簡単に説明します。

注:

Shibboleth 2 の詳細については、Shibboleth 2 のホーム ページ[footnoteRef:23]を参照してください。 [23: Shibboleth 2 ホーム ページ: http://go.microsoft.com/fwlink/?LinkID=256497 (英語)]

Shibboleth (ヘブライ語の「shibbóleth」および関連する聖書での用途 (つまり敵対するグループの潜伏メンバーを見つけ出す) からの引用) は、多数のパートナーに対する ID フェデレーションおよび属性伝達に関する高等教育機関のニーズを満たすために設計されました。Shibboleth プロジェクトは、Internet2/MACE (Middleware Architecture Committee for Education)[footnoteRef:24] によって 2000 年に開始されました。Shibboleth Consortium[footnoteRef:25] が現在主催しているこのプロジェクトは、仕様と、それらを分散システムとして実装するオープン ソース プロジェクトの両方を表します。 [24: Internet2/MACE (Middleware Architecture Committee for Education): http://middleware.internet2.edu/MACE (英語)] [25: Shibboleth Consortium: http://shibboleth.net (英語)]

仕様としての Shibboleth は、OASIS Security Services (SAML) TC[footnoteRef:26] の SAML (Security Assertion Markup Language) 1.1 標準の拡張です。この技術委員会は、Web SSO を実装するために、セキュリティ情報を交換するためのプロトコルを定義しました。 [26: OASIS Security Services (SAML) TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security (英語)]

SAML 1.1 標準は、セキュリティ ドメイン/レルム間、つまり、サービス プロバイダー (SP)、(SAML) アサーションと ID プロバイダー (IdP) の使用者、および (SAML) アサーションの作成者間で認証および承認データを交換するための XML ベースの標準です。

1. SP は、アクセス制御をフィードするために、(SAML) アサーションで受信した信頼できるユーザー属性に応じて、Web リソースを提供します (または提供しません)。

2. IdP は、その認証に基づいてユーザーを認証し、属性を提供します。これが、(SAML) アサーションにおける手段となります。

SAML 1.1 プロファイルでは、ユーザーが IdP から始めると仮定します。ユーザーが最初に SP に接続するシナリオを考慮に入れるために、Shibboleth は SAML ブラウザー/POST およびブラウザー/Artifact プロファイルを拡張しました。

Shibboleth プロジェクトは技術委員会の作業と連携していたので、当初より SAML に関与しています。

そのため、Shibboleth 仕様では次のことが行われています。

1. 認証要求の概念を定義し、SP がブラウザーから一部の認証を要求できるようにします。

2. WAYF (Where Are You From?)[footnoteRef:27] の概念を導入し、ブラウザーが IdP を選択できるようにします。 [27: 現在は探索サービスに変更されています (この章の後半を参照してください)。]

つまり WAYF サービスは、ユーザーをその ID がアカウントとして宣言されているセキュリティ ドメインに (さらに正確に言うなら、このセキュリティ ドメインの IdP に) リダイレクトできるオプションのサービスです。

3. 属性の交換が行われる方法も規定します (これは、SAML 1.1 には当てはまりません)。

実装としての Shibboleth 1.0 は 2003 年にリリースされ、世界中の高等教育機関/研究機関コミュニティによって直ちに採用されました。Shibboleth 1.0 は Shibboleth 仕様を SAML 1.1 拡張として実装します。

SAML 2.0 は OASIS 標準として 2005 年に公開され、Shibboleth 2[footnoteRef:28] は翌年リリースされました。Shibboleth 2 は SAML 2.0 サポート (および Shibboleth 1.3 との下位互換性) を提供します。 [28:  Shibboleth 2.0: http://go.microsoft.com/fwlink/?LinkID=256497 (英語)]

標準自体の前のバージョン (SAML 1.1) と、それを基にした以下の 2 つの拡張/仕様を一本化したものが SAML 2.0 で、これが標準の基盤となっています。

· Internet2 Shibboleth 1.3

· Liberty Identity Federation Framework (ID-FF) 1.2[footnoteRef:29] [29: Liberty Identity Federation Framework (ID-FF) 1.2: http://www.projectliberty.org/resource_center/specifications/liberty_alliance_id_ff_1_2_specifications/?f=resource_center/specifications/liberty_alliance_id_ff_1_2_specifications (英語)]

SAML 1.1 と同様に、ID-FF 仕様はクロス ドメインでブラウザー ベースのシングル サインオン (SSO) フレームワークです。さらに、仕様では信頼の輪 (CoT) の概念が定義されています。参加する各ドメイン/レルムは、ユーザー、使用される認証の種類、および結果として生じる認証資格情報と関連付けられているポリシーを識別するために使用されるプロセスを正確に文書化するものと考えられています。信頼の輪の他のメンバーは、これらのポリシーを調べて、このような情報を信頼するかどうかを判断できます。CoT は静的な信頼スキーマを表します。Liberty Alliance は、フェデレーション仕様を OASIS に提供しました。

ID 市場を拡張するための取り組みにおいて、Liberty Alliance は Liberty Interoperable 認定プログラム[footnoteRef:30] も導入しました。このプログラムは Drummond グループ[footnoteRef:31] によって運営され、前記の ID-FF 仕様のような独自の仕様と SAML 標準のような公開標準に照らして商用およびオープン ソース製品をテストし、製品間の相互運用性のベース レベルを保証するように設計されています。 [30: Liberty Interoperable 認定プログラム: http://www.projectliberty.org/liberty/liberty_interoperable (英語)] [31: Drummond グループ Web サイト: http://www.drummondgroup.com/ (英語)]

本書の執筆時点で、世界各国の多数のベンダーや組織による 80 を超えるソリューションがテストに合格しています。

2009 年 6 月、Liberty Alliance によるすべての作業と関連資料は、Kantara Initiative[footnoteRef:32] (kan-TAR-a: スワヒリ語で「橋」の意、語源となるアラビア語では「調和」の意) に提供されました。このプロジェクトの Web サイトは、Liberty Alliance の作業のアーカイブとして残されています。 [32: Kantara initiative: http://kantarainitiative.org/ (英語)]

Kantara Initiative は、「ネットワークを、プライバシー保護を実現したネイティブで信頼性の高い環境にするため、個人情報の不正使用を防ぎながら、安全な ID ベースのオンラインでのやり取りを確保する活動によって、ID コミュニティの架け橋となり、調和をもたらす」べく取り組んでいます。

この移行の結果、以前は Liberty Alliance が運営していた SAML 2.0 相互運用性認定プログラムは、現在 Kantara Initiative によって運営されています。

SAML 2.0 標準の紹介

OASIS SAML 2.0 標準は仕様のセットであり、一連の標準文書と非標準の文書で構成されています。

· SAML V2.0 Executive Overview[footnoteRef:33] (SAMLExecOvr) [33: SAML V2.0 Executive Overview: http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf (英語)]

· Security Assertion Markup Language (SAML) V2.0 Technical Overview[footnoteRef:34] (SAMLTechOvw) [34: Security Assertion Markup Language (SAML) V2.0 Technical Overview: http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf (英語)]

· Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:35] (SAMLCore): コア仕様 [35: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf (英語)]

· Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:36] (SAMLBind): SAML メッセージを標準のメッセージングまたは通信プロトコルにマップ [36: Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf (英語)]

· Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:37] (SAMLProf): 拡張されたエンタープライズの特定の問題を解決するための SAML の使用に関するユースケースまたは「ハウツー」 [37: Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (英語)]

· Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:38] (SAMLMeta): SAML エンティティ間で信頼を確立するための構成データ (エンドポイント URL、署名検証用の主要マテリアルなど) [38: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf (英語)]

· Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:39] (SAMLAuthnCxt): ユーザー認証メカニズムの詳細な説明 [39: Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf (英語)]

· Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:40] (SAMLConform): SAML 2.0 実装の運用モデル [40: Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf (英語)]

· Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:41] (SAMLSec): SAML 2.0 でのセキュリティとプライバシー双方の分析 [41: Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf (英語)]

· Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0[footnoteRef:42] (SAMLGloss): SAML 2.0 で使用される用語 [42: Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf (英語)]

注:

2005 年の SAML 2.0 標準のリリース以降、OASIS SAML TC は複数の機能強化について取り組みを継続しています。これらの文書は、OASIS SAML TC Web サイトから入手できます。

標準について十分に理解し、たとえば相互運用性の問題を解決するために必要に応じて具体的な詳細を調べることができるように、非標準の SAMLTechOvw 文書を一読することをお勧めします。この文書は、その名が示すとおり、標準とその構成および影響を理解するための鍵を提供します。

SAML 2.0 の重要な側面については、標準文書である SAMLCore、SAMLBind、SAMLProf、および SAMLConform で詳しく説明されています。

SAML 2.0 は、XML ベースのアサーションと、プロトコル、バインディングおよびプロファイルを定義します。SAMLCore コア仕様との関連における「SAML Core」という用語は、SAML アサーションの一般的な構文とセマンティクス、およびシステム エンティティ間でこれらのアサーションの要求と送信を行うために使用されるプロトコルを表します。SAML アサーションは、通常 IdP から SP に転送されます。

Windows Azure AD の用語では、SAML 2.0 は、SAML 2.0 プロトコルとバインディングのサブセットを表します。これは、WS-Federation および WS-Trust ログイン フローで使用される SAML 2.0 アサーションのサポートとは異なります (ただし、SAML プロトコルも SAML アサーションを使用します)。また、AD FS 2.0 および Windows Identity Foundation (WIF) の用語とも異なります。ここでは、SAML はトークンを表し、プロトコルとバインディングを表す場合は SAMLP が使用されます。

SAML 2.0 アサーション

SAML 2.0 アサーションは、(署名付き) (セキュリティ) トークンであり、(セキュリティ) 情報の手段/コンテナーと考えることができます。このようなアサーションには、アサーションに適用されるサブジェクトと条件以外に、アクセス制御の決定を行う、または導き出すために SP が通常使用する「ステートメント」または「クレーム」が含まれています。以下の 3 種類のステートメントが SAML によって提供されます。

· 認証ステートメント: セキュリティ プリンシパルが特定の時点で特定の認証方法を使用して IdP によって認証されていることをアサートします。認証コンテキストをこのようなステートメントとして公開することもできます。

· 属性ステートメント: サブジェクトが特定の属性と関連付けられていることをアサートします。属性は、通常、文字列名-値のペアです。証明書利用者は、これらの属性またはクレームを使用して、アクセス制御の決定を行い、または導き出します。

· 承認決定ステートメント: 特定の証拠が与えられた場合、サブジェクトが特定のリソースで特定のアクションを実行できることをアサートします。

注:

名称の由来である OASIS TC[footnoteRef:43] によって規定される別の OASIS 標準 eXtensible Access Control Markup Language (XACML) の利用を促進するため、語彙は意図的に制限されています。XACML は、ポリシーの解釈方法について記述した、XML ベースの宣言型のアクセス制御ポリシー言語および処理モデルです。 [43: OASIS eXtensible Access Control Markup Language (XACML) TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml (英語)]

本書においては、考慮する必要がある SAML アサーションは、IdP から SP に発行される、いわゆる "ベアラー" アサーション、存続期間の短いベアラー トークン (つまり、所有証明なし) です。このようなアサーションには、認証ステートメントと属性ステートメントの両方が含まれます。

SAML 2.0 プロトコル

SAML 2.0 プロトコルは、特定の SAML 要素 (アサーションを含む) が SAML 要求および応答要素内でどのようにパッケージ化されるかを記述し、IdP や SP などの SAML エンティティがこれらの要素を作成または利用するときに従わなければならない処理規則を提供します。大部分において、SAML プロトコルは単純な要求-応答プロトコルです。

SAML プロトコルは常に送信される内容を表すもので、方法を表すものではないことに注意する必要があります (方法は、バインディングの選択によって決定されます)。

本書においては、最も興味深い SAML プロトコルは、認証要求プロトコル、アーティファクト解決プロトコル、およびシングル ログアウト プロトコルです。

SAML 2.0 バインディング

SAML 2.0 バインディングは、SAML 要求および応答が標準のメッセージングまたは通信プロトコルにどのようにマップされるかを決定します。つまり、SAML プロトコル メッセージの、標準のメッセージング形式または通信プロトコルに対するマッピングとなります。SAML 2.0 は、バインディングの概念を基になるプロファイルから完全に分離します (次のセクションを参照してください)。

SAML 2.0 標準は、複数のバインディングを定義します。

· HTTP リダイレクト (GET) バインディング

· HTTP POST バインディング

· HTTP アーティファクト バインディング

· その他

SAML 2.0 プロファイル

SAML 2.0 プロファイルは、アサーション、プロトコル、バインディングの特定の組み合わせを使用する定義済みのユースケースを具体的に表したものです。検討されるユースケースをサポートするために SAML 2.0 アサーション、プロトコル、およびバインディングがどのように組み合わされるかを詳細に記述します。

SAML 2.0 標準は、複数のプロファイルを定義します。

· Web ブラウザー SSO プロファイル

· アーティファクト解決プロファイル

· シングル ログアウト プロファイル

· ID プロバイダー ディスカバリ プロファイル

· 拡張クライアントまたはプロキシ (ECP) プロファイル

· その他

最も重要なプロファイルは Web ブラウザー SSO プロファイルです。これは、Web SSO およびフェデレーション用の主要な SAML ユースケースであるためです。詳細については、「2.3 相互作用の原則と関連プロファイル」を参照してください。

Shibboleth システム コンポーネントの論理アーキテクチャ

コンポーネントおよびコンポーネント間の相互作用についてのこの説明は、本書の作成者が Shibboleth Consortium がShibboleth サービス プロバイダー[footnoteRef:44] および Shibboleth ID プロバイダー[footnoteRef:45] ソフトウェアを通じて提供するシステムをどのように理解しているかを示すものです。 [44: Shibboleth サービス プロバイダー: http://shibboleth.net/products/service-provider.html (英語)] [45: Shibboleth ID プロバイダー: http://shibboleth.net/products/identity-provider.html (英語)]

注:

Shibboleth については、システムについて説明し、Shibboleth プロジェクトの用語を定義している「Understanging Shibboleth[footnoteRef:46]」を参照してください。 [46: Understanding Shibboleth: https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth (英語)]

「Shibboleth Technical Overview[footnoteRef:47]」というドキュメントを参照することもできます。このドキュメントは Shibboleth バージョン 1.x に関するものですが、主な要素は、本書で取り上げている Shibboleth 2 でも有効です。 [47: Shibboleth Architecture Technical Overview: http://open-systems.ufl.edu/files/draft-mace-shibboleth-tech-overview-latest.pdf (英語)]

フランス語を話すコミュニティ、および特定の環境での計画における考慮事項については、"GIP RENATER" によって提供されるサービスである教育機関および研究機関フェデレーション (いわゆるフェデレーション Education-Recherche) のコンテキストで提供されているリソースをご覧になることをお勧めします。これらのリソースは、フェデレーション Education-Recherche Web サイト[footnoteRef:48].でオンライン提供されています。 [48: フェデレーション Education-Recherche Web サイト: https://services.renater.fr/federation/index (フランス語)]

Shibboleth サービス プロバイダー (SP)

アーキテクチャの観点から見た場合、Shibboleth SP は以下の 3 つの部分で構成されています。

1. アサーション コンシューマー サービス – これは、プロトコルの SSO 部分専用の SP のエンドポイントです。Web フィルターのように動作し、認証されていないユーザーをそのユーザーの IdP にリダイレクトして、認証できるようにします。

これは、オプションの組み込み探索サービス (EDS: Embedded Discovery Service) (以前の名称は WAYF サービス、現時点では SAML 2.0 で廃止予定) と連動して行われる場合があります (実装されている場合)。EDS により、SP は独自のサイト内で探索サービスを実行できます。探索サービスは、OASIS SAML TC の「Identity Provider Discovery Service Protocol and Profile specification[footnoteRef:49]」に準拠します。そのため、探索サービスの外観をサイト上の他のページと同じようにすることができ、ユーザーはまったく異なるサードパーティの探索サービス サイトにリダイレクトされません。EDS は、JavaScript ファイルと CSS ファイルのセットなので、簡単にインストールして使用でき、追加のソフトウェアも必要としません[footnoteRef:50]。 [49: Identity Provider Discovery Service Protocol and Profile specification: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf (英語)] [50: EDS を使用するには、Shibboleth SP バージョン 2.4 以上がインストールされて構成されている必要があります。]

プロトコル プロファイルに応じて、アサーション コンシューマー サービスは、SAML アサーションを受信し、オプションで IdP から追加属性を取得するか、またはユーザー アーティファクト (SAML アーティファクトは SAML アサーションへの参照です) を受信し、ユーザー アサーションと属性を IdP から取得します。最終的に、要求されたアプリケーション リソースへクライアントをリダイレクトします。収集された属性は、適用可能なリソースへのアクセスを許可するかどうかを決定するアクセス コントローラーに送信されます。

2. 属性リクエスター – ユーザー アーティファクト (一部のプロトコル プロファイルで使用) に基づいて、このコンポーネントは IdP からユーザー属性を取得します。これは、ブラウザーを使用せずに、リダイレクトを通じて直接行われます。

3. アクセス制御 – このコンポーネントは、その名が示すとおり、適用可能なリソースへのアクセスを許可または拒否します。

z ( ID プロバイダー 組み込み 探索 サービスクライアント アサーション 属性 コンシューマー リクエスター サービス アクセス アプリケーション 制御 リソース サービス プロバイダー (SP) Internet2 Shibboleth 2)

本書の執筆時点で、Shibboleth SP の最新の安定したリリースは、ソフトウェアのバージョン 2.5.0[footnoteRef:51] です。Shibboleth SP ソフトウェアについては、Windows Azure AD がこの役割を担う限り、これ以上本書では取り上げません。 [51: Index of /downloads/service-provider/latest: http://shibboleth.net/downloads/service-provider/latest/ (英語)]

Shibboleth ID プロバイダー (IdP)

一方、Shibboleth IdP は以下の 4 つの要素で構成されています。

1. 認証/SSO サービス: このサービスは、IdP にリダイレクトされたユーザーを認証します。

これは、IdP の内部部分ではありませんが、IdP はユーザーを認証するコンポーネントがなければ約立ちません。このサービスは、IdP、具体的には認証機関にユーザーの一意識別子を送信する必要があります。この一意識別子は、ユーザーの属性を準備および生成するために使用されます。実際には、Web 認証で利用できる任意のメカニズム (これには、プロトコルおよびユーザー データ ソースが含まれます) を使用できます。これは、Web SSO 認証システムである場合があります。

CAS (Central Authentication Service)[footnoteRef:52] Web SSO サービス (もともとエール大学[footnoteRef:53] で開発されました) との統合は非常に一般的であり、フランスの大学等で行われています。CAS は一般に、認証と Web SSO を実行するためにのみ使用されます。 [52: Service CAS (Client Authentication Service): http://www.jasig.org/cas (英語)] [53: CAS は、2004 年 12 月に Jasig プロジェクトになりました。]

注:

Shibboleth IdP および CAS Web SSO を一貫したソリューションとして統合する方法については、記事「Shibboleth-CAS Integration[footnoteRef:54]」を参照してください。これについての詳しい内容は、Windows Azure AD/Office 365 を Shibboleth 2 ID フェデレーション用の SP にする方法に重点を置く本書の対象ではありません。 [54: Shibboleth-CAS Integration: https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration (英語)]

2. 認証機関: この機関は、名前識別子アーティファクト (不透明な識別子) を前記のユーザー一意識別子と関連付けます。

3. 属性機関: この機関は、Web サービスを通じて SP 呼び出しに応答します。これらの呼び出しは、ユーザー名識別子を提供し、対応するユーザー属性を必要とします。ユーザー名識別子とユーザー属性の関係は、認証機関によって維持されます。さまざまなデータ ソース (Active Directory、その他の LDAP ディレクトリ、SQL データベースなど) をユーザー リポジトリとして使用できます。Shibboleth 2 実装は、一度に複数のデータ ソースを処理できます。

4. アーティファクト解決サービス: このサービスは、ユーザー アーティファクトから認証アサーションへの変換の関係で、Web サービスを通じて SP 呼び出しに応答します。

( ID プロバイダー (IdP) Internet2 Shibboleth 2 認証機関 属性機関 SSO アーティファクト サービス 解決サービス 探索 クライアント サービス サービス プロバイダー)

Shibboleth 2 IdP 技術実装は、Servlet 2.4 仕様に基づく Java Web アプリケーションです。Apache Tomcat 6 (7 ではありません) などの Java EE servlet コンテナーを必要とします。Tomcat の前に Apache Web サーバーを置いて使用することもできます。

Shibboleth IdP の最新の安定したリリースは、ソフトウェアのバージョン 2.3.8[footnoteRef:55] です。現時点では、これより前の安定したリリースは存在しません。 [55: Index of /downloads/identity-provider/latest: http://shibboleth.net/downloads/identity-provider/latest/ (英語)]

相互作用の原則と関連プロファイル

既に説明したとおり、Shibboleth 2 は Shibboleth 1.3 との下位互換性を提供し、結果として SAML 1.1 のプロファイルをサポートします。

マイクロソフトとの関連でより興味深いのが、前記の SAML 2.0[footnoteRef:56] のサポートです。 [56: Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996 (英語)]

「2.1.4 SAML 2.0 プロファイル」で説明したとおり、SAML 2.0 は重要な数のプロファイルを定義します。本書で主に対象となるのは、以下のプロファイルです。

· Web ブラウザー SSO プロファイル

· シングル ログアウト プロファイル

· 拡張クライアントまたはプロキシ (ECP) プロファイル

相互作用の原則を簡単に説明するため、Web ブラウザー SSO プロファイルについて考えてみましょう。

交換は、SP 側への要求によって始まります。"SP 開始" と呼ばれるこの最新のアプローチは、優れた柔軟性を提供しますが、名前の由来であるプロファイルへの参照として、SAML 2.0 用語でいう ID プロバイダー ディスカバリの問題を引き起こします。これは、Where Are You From (WAYF) およびホーム レルム ディスカバリ (HRD) の問題とも呼ばれます。(IdP が選択される方法 (WAYF など) は定義されていません。)

注:

SP 開始は新しい追加事項であり、推奨されるアプローチですが、SAML の前のバージョンで導入された IdP 開始アプローチも引き続きサポートされています。ただし、推奨されるアプローチではなくなりました。

柔軟性つまりプロファイル内の組み合わせから考えられる展開の数を示す場合、SP から IdP への初期のリダイレクトは、HTTP リダイレクト経由だけでなく、HTTP POST 経由または HTTP アーティファクトと呼ばれるバインディング経由 (HTTP リダイレクトおよび HTTP 経由での SOAP メッセージ交換をベースとします) でも可能です。したがって SP は、4 つのバインディング (HTTP リダイレクト、HTTP POST、および 2 つの種類の HTTP アーティファクト) から選択できます。

認証アサーションは、HTTP POST 経由または HTTP アーティファクト バインディング経由で送信されます。したがって、IdP には 3 つのバインディング オプション (HTTP POST と、2 つの形式の HTTP アーティファクト) があります。

このため、Web ブラウザー SSO プロファイルの考えられる展開は合計 12 個になります。

たとえば、"SP 開始 SSO: リダイレクト/POST バインディング" は、SP が開始する SSO 交換を記述します。ここで、HTTP リダイレクト バインディングは メッセージを IdP に配信するために使用され、HTTP POST バインディングはアサーションを含む メッセージを SP に返すために使用されます。

後の「5.2 パッシブ/Web プロファイル認証フローについて」では、Windows Azure AD によるシングル サインオンの特定のコンテキストにおけるこのプロファイルの展開について、より具体的に説明します。詳細については、このセクションを参照してください。

同様に、「5.3 ECP – プロキシ認証プロファイル認証フローについて」では、Windows Azure AD によるシングル サインオンの特定のコンテキストにおいてオプションでサポートされている ECP プロファイルの展開について、具体的に説明します。

(ログアウト機能が説明されている構成に含まれている場合でも、シングル ログアウト プロファイルについては説明しません。)

フェデレーション メタデータの定義

Shibboleth 2 システムでは、フェデレーションのメンバー間の異なる信頼関係が (フェデレーション) メタデータとして実装されます。それらは、SAML 2.0 SAMLMeta 文書にあるとおり、フェデレーション信頼の基盤です。

SP が IdP フェデレーションによって認識されるには、フェデレーション メタデータ内に記載されている必要があります。同様に、IdP がフェデレーション内の SP によって認識されるには、フェデレーション メタデータ内に記載されている必要があります。Shibboleth SP は、ホワイトリストを定義することによって、フェデレーション内の IdP のサブセットのみを認識できます。さらに、ローカル ニーズのために、IdP と SP はメタデータ ファイルを交換することによって互いを信頼できます。

Shibboleth 2 技術実装は、自動的にメタデータを http(s):///idp/profile/Metadata/SAML という URL に公開します。この URL は、IdP との相互信頼関係で、またはフェデレーション内での登録のために使用できます。

各プロバイダーのメタデータには、URN (Uniform Resource Name、RFC 2141 URN 構文[footnoteRef:57] を参照) 形式のプロバイダーの一意識別子 (entityID 属性)、組織および技術担当者の住所、このプロバイダーが使用する証明書の名前、IdP の証明機関 URL と属性機関 URL (属性要求の場合)、または SP のアサーション コンシューマー サービス URL (属性受信用) が含まれます。 [57: RFC 2141 URN 構文: http://tools.ietf.org/html/rfc2141 (英語)]

メタデータには、フェデレーション内で信頼される証明書を発行する証明機関 (CA) も含まれます。

注:

詳細については、Shibboleth Community Wiki のオンライン ヘルプ トピック「NativeSPMetadataProvider[footnoteRef:58]」を参照してください。 [58: NativeSPMetadataProvider: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMetadataProvider (英語)]

これらのメタデータは通常 XML ファイルとして表されます。整合性を確保するために、このファイルは通常デジタル署名されます。実稼働環境のフェデレーションでは、新しいプロバイダーの記録または既存のプロバイダーに関する情報の更新は、要求が有効かつ正当であることを確認するプロセスを経ることになります。

フェデレーションで、XML ファイルは一元管理され、相互信頼のためにフェデレーション内のすべての IdP および SP によって使用されます。この側面については、後で説明します。

Windows Azure AD/Office 365 でのフェデレーション認証

Shibboleth 2 を構成するためのオプションは個々の企業によって異なり、期待される動作およびエクスペリエンスを知ることが重要になります。SharePoint Online で作成された匿名アクセス用のインターネット サイトの場合を除き、Office 365 サービスにアクセスするにはユーザーの認証が必要になります。

そのため、Windows Azure AD は 2 種類の ID を提供します。

1. Microsoft Online Services クラウド ID (クラウド ID): ユーザーは他のデスクトップ資格情報または自社運用の資格情報とは別に、Windows Azure AD にサインインするためのクラウド資格情報を受け取ります。クラウド ID は、サービス/クラウドで管理されます。

注:

オプションのディレクトリ同期により、社内で管理されるユーザー ID をクラウド ID の形式でサービス/クラウドに同期することができます。

2. フェデレーション ID: 自社運用の ID を持つ企業では、前記のシングル サインオン機能を活用できます。ユーザーは、自身の社内資格情報を使用して Windows Azure AD にサインインし、Office 365 のサービスにアクセスできます。ユーザーの ID は社内で管理され、フェデレーション ID の形式でサービスに同期されます。

ユーザーは、有効な資格情報を入力するプロンプトを通じて、または CAS (Central Authentication Service) Web SSO サービスが構成されている場合はシングル サインオン プロセスを通じて、Windows Azure AD ユーザー アカウントの認証を受けることで、Office 365 のサービスにアクセスできます。一度認証されたユーザー ID は、Windows Azure AD アカウントに関連付けられたユーザー名を参照します。上記の内容を考慮し、3 種類の認証が用意されています。

1. クラウド ID

2. クラウド ID + ディレクトリ同期 (DirSync ツールまたは Windows Azure AD connector for FIM 2010)

3. フェデレーション ID + ディレクトリ同期 (DirSync ツールまたは Windows Azure AD connector for FIM 2010)

上記の ID の種類 (クラウドかフェデレーションか) は、ユーザー エクスペリエンス、管理要件、展開に関する考慮事項、および Windows Azure AD と Office 365 サービスの機能に影響します。

以下は、エクスペリエンスを簡単に分類したものです。

· クラウド ID によるユーザー エクスペリエンス: ユーザーはクラウド ID でサインインします。クラウド ID は、ユーザー名とパスワードを入力する、従来型のチャレンジ/応答によって認証されます。認証はクラウドで行われます。ユーザーは常に資格情報を求められます。

上記のとおり、ユーザーには 2 つの ID があります。つまり、自社運用サービスにアクセスする ID と、Windows Azure AD 用の ID (つまりクラウド ID) です。したがって、ユーザーは、自社運用環境にログインしているときでも、Office 365 のサービスにアクセスするときは資格情報を求められます。この負担は実際には多くの場合、資格情報を求められたところでパスワードの保存オプションを選択することによって軽減することができます。

· フェデレーション ID によるユーザー エクスペリエンス: ユーザーは、オンライン サービスおよび社内サービスにアクセスするために社内 ID でサインインします。つまり、Office 365 のサービスにアクセスするときは、Shibboleth 2 を使用して認証されます。認証は、組織の ID 環境に対して社内で行われます。CAS Web SSO サービスが構成されている場合、ユーザーには本当の意味での SSO が提供されます。

· クラウド ID による管理者エクスペリエンス: 組織の管理者は、クラウドと自社運用環境の両方でパスワード ポリシーを管理します。クラウド ID のパスワード ポリシーは、Windows Azure AD と合わせてクラウドに格納されます。パスワード リセットは、自社運用の ID およびクラウド ID について管理する必要があります。したがって、ユーザーは、ポリシーに従って両方のパスワードを変更する必要があります。

· フェデレーション ID による管理者エクスペリエンス: 組織の管理者は、自社運用環境でのみパスワード ポリシーを管理します。したがって、フェデレーション ID のパスワード リセットを気にかける必要はありません。組織の ID インフラストラクチャがパスワード ポリシーを格納し、制御します。パスワード リセットは、自社運用の ID でのみ発生します。

( お客様の自社運用環境 信頼関係 ID プロバイダー (IdP) 認証 プラットフォーム サインイン サービス DirSync ツール ディレクトリ プロビジョニング ストア -または- - または- プラットフォーム FIM 2010 および Windows AD以外の Azure AD コネクタディレクトリ ストア Microsoft Online ポータル (MOP)/ Windows PowerShell/ GRAPH)

本書では、このような状況におけるシングル サインオン機能とフェデレーション ID について説明します。したがって、ユーザー アカウントの作成、パスワード ポリシーなどの Windows Azure AD クラウド ID の特定の情報については、開始点として「Office 365 ID サービスの説明[footnoteRef:59]」を参照してください。 [59: Office 365 ID サービスの説明: http://www.microsoft.com/ja-jp/download/details.aspx?id=13602]

フェデレーション ID のサインイン エクスペリエンス

サインイン エクスペリエンスは、使用している Windows Azure AD ID の種類によって異なります。エンド ユーザーのサインイン エクスペリエンスは、クライアントの種類によって異なります。

次の表は主な組み合わせについて示したものです。結果的にどのようなサインイン エクスペリエンスになるかを説明する際に役立ちます。このシングル サインオン シナリオでは、限られたクライアントのセットのみがサポートされていることに注意してください。

アプリケーション

社内ネットワーク内

社内ネットワーク外

Microsoft Online ポータル、SharePoint Online、Office Web Apps

クリックしてサインインするよう求めるポップアップが表示されます。資格情報を要求されます

Outlook Web Apps

資格情報の入力を求められます

SharePoint Online を使用した Office 2010/Office 2007 アプリケーション

クリックしてサインインするよう求めるポップアップが表示されます。資格情報を要求されます

Outlook 2010/Outlook 2007、Exchange ActiveSync、POP、IMAP

最初の接続時 (およびパスワード変更時) に資格情報を求められます。パスワードを記憶するためのチェック ボックスが表示されます。

Outlook ユーザーは、最初に使用する際に社内資格情報の入力を求められます。その時点で、今後の使用のためにパスワードを保存することを選択できます。この場合、エンド ユーザーは、パスワードを変更するまで再度入力を求められることはありません。ただしこれは、組織のパスワード ポリシーによって異なります。

Shibboleth 2 IdP を CAS (Central Authentication Services) Web SSO サービスと統合すると、サインインのエクスペリエンスがさらに向上します。

フェデレーション ID の認証の種類

ここでは、Windows Azure AD および Office 365 のサービスでフェデレーション ID に対して機能するユーザー認証の種類について説明します。

次の表は、フェデレーション ID による複数の認証メカニズムを示しています。

アプリケーション

認証メカニズム

Web ブラウザー

Web サインイン、SAML 2.0 Web ブラウザー SSO プロファイル (Shibboleth 2)

Microsoft Office 2007/Office 2010 (Word、Excel、および PowerPoint)

Web サインイン、SAML 2.0 Web ブラウザー SSO プロファイル (Shibboleth 2)

Outlook 2007/Outlook 2010、Exchange ActiveSync、POP/IMAP/SMTP クライアント

サインイン、SAML 2.0 ECP プロファイル (Shibboleth 2)

Web ブラウザーからの認証

Office 365 では、Microsoft Online ポータル (MOP)、Windows Azure Active Directory 管理ポータルのプレビュー版、SharePoint Online、Outlook Web App (OWA) など、Web ブラウザーを使用してアクセスできるサービスが複数提供されています。

Shibboleth 2 によるシングル サインオン シナリオは、上記の Web ベースのサービスをサポートします。これには、SharePoint Online リソースにアクセスするための Office 2007 または Office 2010 アプリケーション (Word、Excel、および PowerPoint) も含まれます。

ブラウザーからこれらのサービスにアクセスすると、サインイン資格情報を入力するサインイン ページにリダイレクトされます。

フェデレーション ID の場合、サインイン エクスペリエンスは次のようになります。

1. Web ブラウザーは Windows Azure AD サインイン サービスにリダイレクトされます。ここで、たとえば自社運用の Active Directory 環境の場合は、ユーザー プリンシパル名 (UPN)[footnoteRef:60] 形式で社内 ID (IETF 標準 ARPA インターネット テキスト メッセージに関する RFC 822 標準[footnoteRef:61]に従って書式設定) を入力します (例: johndoe@idmgt.com)。Windows Azure AD サインイン サービスでは、ユーザーがフェデレーション ドメインに属していることが判別され、認証のため自社運用の Shibboleth 2 IdP サービスにリダイレクトされます。 [60: User-Principal-Name 属性: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx (英語)] [61: RFC 822 Standard for ARPA Internet Text Messages: http://tools.ietf.org/html/rfc822 (英語)]

2. 次に、Shibboleth 2 IdP に対して認証され、Shibboleth 2 IdP は SAML 2.0 ログオン トークンを生成します。Web ブラウザーは、このトークンを Windows Azure AD サインイン サービスにポストします。サインイン サービスはログオン トークンを使用して認証トークンを生成し、要求された Office 365 のサービスに対して Web ブラウザーからトークンがポストされることで、ログインが可能になります。

リッチ クライアント アプリケーションからの認証

Shibboleth 2 によるこのシングル サインオン シナリオでは、以下のような、基本認証およびサポート対象の Exchange アクセス方法 (IMAP、POP、Exchange ActiveSync (EAS)、MAPI など) を使用する電子メール リッチ クライアントのみがサポートされます。

· Microsoft Outlook 2007

· Microsoft Outlook 2010

· Thunderbird 8 および 9

· iPhone (iOS の各バージョン)

· Windows Phone 7.x

他のクライアントはいずれも、Shibboleth 2 IdP によるこのシングル サインオン シナリオではサポートされません。たとえば、Lync 2010 デスクトップ クライアントは、Windows Azure AD によるシングル サインオン用に Shibboleth 2 が構成されているサービスへのログインについてはサポートされていません。

Shibboleth 2 IdP 用に展開するには、拡張クライアント プロトコル (ECP) エンドポイントが必要です。

SSO 構成および関連する考慮事項について

Shibboleth 2 によるシングル サインオン機能をセットアップするために実行する必要があるすべてのインストール手順と関連するオプションについては、Microsoft TechNet の記事「シングル サインオンのロードマップ[footnoteRef:62]」および「Shibboleth ID プロバイダーによるサインオンを実装して管理する[footnoteRef:63]」を参照してください。 [62: シングル サインオンのロードマップ: http://technet.microsoft.com/ja-jp/library/hh967643] [63: Shibboleth ID プロバイダーによるシングル サインオンを実装して管理する: http://technet.microsoft.com/ja-jp/library/jj205456]

シングル サインオンの準備

Microsoft TechNet の記事「シングル サインオンを準備する[footnoteRef:64]」には、組織の自社運用の IT 環境を、シングル サインオンを導入しフェデレーション ID を正しく展開するために準備する際に実行する必要がある操作が記載されています。当然ながら、自社運用環境の準備は、組織が Active Directory を使用するか AD 以外のディレクトリを使用するかによって異なります。 [64: シングル サインオンを準備する: http://technet.microsoft.com/ja-jp/library/jj151786]

さまざまなデータ ソース (Active Directory、その他の LDAP ディレクトリ、SQL データベースなど) を活用できる Shibboleth 2 では、この点を考慮に入れる必要があります。

自社運用の AD 環境での Shibboleth 2

上記の Microsoft TechNet の記事に記載されているとおり、シングル サインオンと適切に連動させるためには、組織の自社�