Visual Studio 2013 を使用した SSO 開発については「Azure Active Directory の SSO 開発 (Visual Studio 2013 編)」を参照してください。(この投稿は、古い情報です。)

環境 :
Windows Azure Active Directory (AAD) Developer Preview
Visual Studio 2012
ASP.NET and Web Tools 2012.2 (ASP.NET Fall 2012) Update BUILD Prerelease
Microsoft ASP.NET Tools for Windows Azure Active Directory – Visual Studio 2012
Active Directory Authentication Library (ADAL) Beta
Windows PowerShell
Windows PowerShell 用 Microsoft Online Services モジュール

こんにちは。

Azure Team Blog でアナウンスされたように、Windows Azure Active Directory (Preview) が拡張され、SAML-P 対応、Graph API の拡張など、いくつか魅力的なアップデートがありました。(Graph API の投稿 も、今回の更新を反映しました。)

今回は、その拡張 (Enhancement) の 1 つである、Web SSO のツール対応について記述します。以前掲載した「Web SSO (Identity and Access Tool 編)」では、Indentity and Access Tool というアドオンをインストールして使用しましたが、今回のツールは、ASP.NET と統合された形で、かつ、後述のように、いくつかのステップが簡略化され、Windows Azure Active Directory に詳しくない開発者でも使いやすくなっています。

利用手順

まず、ASP.NET and Web Tools 2012.2 (Web Platform Installer よりインストール可能) と Microsoft ASP.NET Tools for Windows Azure Active Directory – Visual Studio 2012 を Visual Studio の環境にインストールしてください。

では、簡単に構築手順を見て行きましょう。

Visual Studio で、ASP.NET MVC のプロジェクトを新規作成します。この際、[イントラネット アプリケーション] を選択してください。

プロジェクトを右クリックすると [Enable Windows Azure Authentication] メニューが表示されるので、これを選択します。最新版では、[プロジェクト] メニューから [Enable Windows Azure Authentication] を選択してください。(2013/02 訂正)

メニューを選択して表示されるダイアログ ボックス (下図) で、SSO を構成したい Windows Azure Active Directory のテナントのドメインを入力します。

上図で [Enable] ボタンを押すとログイン画面が表示されるので、Windows Azure Active Directory のテナント管理者のアカウント情報 (ID, パスワード) を入力してサインインします。

なんと、以上で完了です !
これにより、以下のセットアップがすべて完了します。

• SSL (https) の有効化
• 構成ファイル (.config) への Identity 関連の設定 (WIF の Identity and Access Tool 同様の設定)
• Windows Azure Active Directory のテナントへの Service Principal の追加

と、カッコよく行きたかったのですが、現在 (2012/11/09)、バグだと思うのですが、下記の太字の設定がおこなわれないようなので、追加しておいてください。(この辺りは、まだ Preview 版ですので許してあげてください。)

<?xml version="1.0" encoding="utf-8"?><configuration>  . . .  <system.webServer>. . .<modules>  <remove name="FormsAuthentication" />  <add name="WSFederationAuthenticationModule" type="..." .../>  <add name="SessionAuthenticationModule" type="..." .../>  . . .

上記の 3 番目の設定 (Service Principal の追加) がおこなわれる点に注目してください。「Web SSO (Identity and Access Tool 編)」では、あらかじめ Windows PowerShell を使用して Service Principal を作成しておく必要がありましたが、今回は、この設定も自動化されています。
試しに、Windows PowerShell で Windows Azure Active Directory のテナントにログインし (「Windows Azure Active Directory と事前準備」を参照)、以下のコマンドで Service Principal を確認すると、下記の通り Service Principal が自動で作成されているのが確認できます。(Id などは、もちろん環境によって異なります。)

> Get-MsolServicePrincipal -All. . .ExtensionData : System.Runtime.Serialization.ExtensionDataObjectAccountEnabled: TrueAddresses : {Microsoft.Online.Administration.RedirectUri}AppPrincipalId: 8314c07f-cbab-465b-a491-ef3081d2c43eDisplayName   : My test appObjectId  : cc0a8bcc-4e41-411f-a314-f1a7fe78ceb3ServicePrincipalNames : {8314c07f-cbab-465b-a491-ef3081d2c43e,WebApp/localhost:44300}TrustedForDelegation  : False

動作は「Web SSO (Identity and Access Tool 編)」と同様です。
F5 でデバッグ実行をおこなうと (この際、プロジェクトのプロパティを確認し、https のアドレスのほうを表示してください)、下図の通り Windows Azure Active Directory (すなわち、Office 365) のログイン画面が表示されます。
クレームの取得方法や、Multi-tenant 対応などについては、「Web SSO (Identity and Access Tool 編)」で解説した内容と同様です。(ここでは、説明を省略します。)

Windows Azure への発行と Service Principal の追加設定

さて、上記の Service Principal (PowerShell の出力結果を参照) を見てお気づきと思いますが、この設定では、デバッグ実行、すなわち、localhost の Relying Party しかサポートされていません。このアプリケーションを Windows Azure に発行して使う場合、結局、Service Principal の追加が必要になります。
しかし、安心してください。ここも自動化されています !

例えば、上記のプログラムを Windows Azure Web Sites に発行してみます。

まず、Windows Azure Preview Portal (https://manage.windowsazure.com/) を開き、Web サイト (WebSites) を作成し、ポータルから Publish Profile (発行プロファイル) をダウンロードします。

Visual Studio のプロジェクトを右クリックして、[発行] (Publish) メニューを選択し、表示される画面で [Import] ボタンを押して、上記でダウンロードしたプロファイルをインポートします。

以降は、ウィザードに従って発行をおこないます。つまり、ここまでは、従来の Azure Web Sites への発行方法と、まったく同じです。

さて、従来だと、これで発行が終了しますが、今回は、下図の通り、Windows Azure Active Directory の設定を追加する画面が表示されます。(上記同様、このあと、Windows Azure Active Directory のログイン画面が表示されます。)

発行が完了したら、Service Principal を確認すると、下記太字の通り、Azure Web Sites に発行したアプリケーション専用の Service Principal が追加されます。

> Get-MsolServicePrincipal -All. . .ExtensionData : System.Runtime.Serialization.ExtensionDataObjectAccountEnabled: TrueAddresses : {Microsoft.Online.Administration.RedirectUri}AppPrincipalId: 8314c07f-cbab-465b-a491-ef3081d2c43eDisplayName   : My test appObjectId  : cc0a8bcc-4e41-411f-a314-f1a7fe78ceb3ServicePrincipalNames : {8314c07f-cbab-465b-a491-ef3081d2c43e,WebApp/localhost:44300}TrustedForDelegation  : FalseExtensionData : System.Runtime.Serialization.ExtensionDataObjectAccountEnabled: TrueAddresses : {Microsoft.Online.Administration.RedirectUri}AppPrincipalId: f5f39f64-79b8-4e02-9c62-022df0a994d6DisplayName   : My test appObjectId  : d864022b-3ce2-4891-bfba-c8450210e4c7ServicePrincipalNames : {f5f39f64-79b8-4e02-9c62-022df0a994d6,WebApp/tsmatsuz-website1.azurewebsites.net}TrustedForDelegation  : False

また、発行されたファイルを ftp などでダウンロードして Web.config を確認すると、Web.config の内容も上記の新しい Service Principal に書き換わっていることが確認できます。(動作は、これまでと同様です。)

Service Principal の追加や、追加された情報に基づく Federation 設定など、面倒で、知識が必要な作業を可能な限り自動化しようという方針が見てとれますね。アイデンティティ関連は、どうしても敷居の高い実装になりますが、開発者の方にとって、もっと身近な存在になっていくことを期待します。