こんにちは。

前回、新しい WIF を使った面倒な話を書いて誤解させてしまったかもしれないので、今回は、そのフォローアップとして、新しい WIF 4.5 の魅力について紹介しようと思います。

これまで追加のユーティリティー (および、ライブラリー) として提供されていた WIF (Windows Identity Foundation) は、.NET Framework 4.5 からは、.NET 標準のライブラリーとして組み込まれており、WIF (Windows Identity Foundation) 関連のライブラリーやツールも改良されています。そうした改良のポイントを、以下に簡単に紹介します。

なお、この分野をキャッチアップされている方は既にご存じだと思いますが、新しい WIF 4.5 については、弊社 (Microsoft) の Identity の Expert である Vittorio が「What’s New in Windows Identity Foundation in Microsoft .NET Framework 4.5」(Tech Ed 2012 US) で解説していますので、是非、参考にしてみてください。(いつもの、ラテンで、陽気な感じです)

ライブラリーの改善

WIF 4.5 のライブラリーは、単に、今まで Microsoft.Identity 名前空間だったクラスが System.Identity に統合されたという簡単な変更だけではありません。いくつかの既存のクラス構成や考え方も改良されています。

例えば、従来の GenericPrincipal、WindowsPrincipal などは、今回から、すべて ClaimsPrincipal から継承されています。(IClaimsPrincipal、IClaimsIdentity は、もう不要です。ClaimsPrincipal.Current で、現在の Principal を取得できます。)
このため、例えば、Windows 認証やメンバーシップ プロバイダーを使った認証など、すべての認証に共通に、Claim を使った属性の取得などが可能です。

また、Pain のいくつかも改善されています。例えば、従来、WCF の RP (Relying Party) を構築する際は、FederatedServiceCredentials.ConfigureServiceHost メソッドを実行して構成する必要がありました。このため、IIS ホストの場合には、カスタムの ServiceHostFactory を構成するなど、やや面倒なプログラム コードの記述が必要でした。
今回 (WIF 4.5) からは、WCF の構成 (.config) で、useIdentityConfiguration と identityConfiguration を使用して、こうした WCF サービス (RP など) が構成レベルで簡単に実装できるようになっています。この具体的なサンプル コードは、下記の「ClaimsAwareWebService」に入っていますので、是非参考にしてみてください。(このサンプルは、Visual Studio のサンプル ギャラリーからも取得できます。)

[Vibro.NET] Windows Identity Foundation in the .NET Framework 4.5 Beta: Tools, Samples, Claims Everywhere

http://blogs.msdn.com/b/vbertocci/archive/2012/03/15/windows-identity-foundation-in-the-net-framework-4-5-beta-tools-samples-claims-everywhere.aspx

なお、本箇所だけでなく、WIF 4.5 では、構成内容 (.config) 全般に、いくつか変更がおこなわれています。

また、Claim を扱った処理も、AddClaim、FindFirst、HasClaim などのメソッドを使って直接 処理できるようになっています。(今までは LINQ を使って取得するなど、やや面倒でした。こちらのコード を参照してください。)

なお、削除された API もあるので注意してください。
前回、このブログでも記載しましたが、AD FS 2.0 連携で使用していた WCF 用の Binding は無くなっています。これらを使用するには、自分で Custom Binding を構成する必要があります。(「.NET 4.5 で Active Authentication を実装する」を参照してください。)
この他に、いくつかの細かなクラスも internal に変更されているものがあるので注意してください。(これらは、一般の開発者は使用できません。)

Identity and Access Tool (新しくなったユーティリティ)

また、従来、WIF に入っていた FedUtil.exe ユーティリティ ([サービス参照の追加] メニュー) の後継として、Identity and Access Tool が提供されています。(最近、Visual Studio 2012 RC 版にも対応しました！)
このユーティリティーをインストールすると、下図の通り、Visual Studio に [Indentity and Access] メニューが表示され、このメニューを選択することで、今までのように、RP (Relying Party) 用の WIF の構成 (.config の設定) をおこなうことができます。(FedUtil.exe の使い方については、「Windows Azure Access Control Service (ACS) を利用する」 を参照してください。)

補足 : Identity and Access Tool は、Visual Studio 拡張マネージャーからインストールできます。

Identity and Access Tool では、新しい付加価値もいくつか提供しています。

例えば、開発用 (デバッグ用) の STS のプロセスを立てて、WIF を使った開発がローカルでおこなえるようになっています。デバッグ実行すると、LocalSTS のプロセスが起動します。(このローカル プロセスの設定は、LocalSTS.exe.config ファイルに記述されます。)

また 今回から、STS として、Azure ACS (Azure Active Directory) を使用する際と、AD FS など他の WS-Federation のサーバーを直接使用する場合に設定がわかれていて、Azure ACS を使用した場合は、ACS 側の証明書利用者アプリケーション (Relying Party) や規則ルール (Rule) の設定も、このツールから自動的におこなわれます。(つまり、ACS との連携が強化されています。なお、ツールが作成したルールは、アプリケーションにあわせて、開発者の皆さん自身で、適宜変更してください。)

Web アプリケーション (ASP.NET MVC など) とより柔軟に連携

ASP.NET MVC との統合も、より簡単になっています。
例えば、ASP.NET MVC のプロジェクトでは、通常、下図のように、右上に [log in] のリンクが表示されています。利用者の期待としては、ここをクリックして はじめてログイン画面が表示され、それ以外の処理は Anonymous (匿名ユーザー) で利用したいと思うでしょう。こうした要件に応じたカスタマイズも非常に簡単です。

まず、Identity and Access Tool で RP を構成した場合、既定の設定では、Anonymous でアクセスした場合、ただちに STS にリダイレクトされてしまいます。

そこで、下図の通り、Identity and Access Tool で [Redirect to the following address] にチェックをおこない、ここにリダイレクト先の URL を入力します。

上図の通り構成変更すると、Web.config は、下記の通り変更されます。(Anonymous user の場合、リダイレクトが抑制されるようになります。)

<configuration>  . . .  <system.web>    <authentication mode="Forms">      <forms loginUrl="~/Account/Login" />    </authentication>    <!-- anonymous user can access -->    <!--<authorization><deny users="?" /></authorization>-->    . . .  </system.web>  . . .  <system.identityModel.services>    <federationConfiguration>      <cookieHandler requireSsl="true" />      <wsFederation passiveRedirectEnabled="false"        issuer="https://adfstest.accesscontrol.windows.net/v2/wsfederation" . . . />    </federationConfiguration>  </system.identityModel.services></configuration>

ログイン処理に相当する /Account/Login では、下記の通り、WIF を使って SignIn メソッドを呼び出すだけです。この SignIn メソッドにより、WIF のフレームワークが STS へリダイレクトをおこない、STS 側の認証完了後に、returnUrl に戻ってきます。

. . .using System.IdentityModel.Services;[AllowAnonymous]public ActionResult Login(string returnUrl){  if (string.IsNullOrEmpty(returnUrl))    return RedirectToAction("Login",      "Account",      new { returnUrl = "/Home/Index" });  FederatedAuthentication.WSFederationAuthenticationModule    .SignIn("passive");  return new EmptyResult();}

Web アプリケーション (RP) では、上記の通り、通常のフォーム認証 (及び、authentication cookie) を使用しているので、[Authorize] 属性 (フィルター) の設定されたアクションでも、ちゃんと STS (ACS, IdP) と連携し、IdP のログイン画面が表示されて、該当のアクションに戻ってきます。
もちろん、SignOut メソッドもあります。

まるで、DotNetOpenAuth のように簡単に RP が実装できますね。

ACS を使用した場合、上記では、ACS が提供する既定のログイン ページ (ACS が提供する Identity Provider の Selector 画面) にリダイレクトされますが、ACS のログイン ページ統合 (Login Page Integration) のスクリプト ソースを組み合わせて使うと、このログイン ページ (Identity Provider の Selector 画面) も自分でホストして、独自な UI で表示できます。この手法は、Vittorio が、下記でステップ・バイ・ステップで紹介していますので参考にしてください。

[Vibro.NET] Taking Control of the HRD Experience with the New WIF 4.5 Tools

http://blogs.msdn.com/b/vbertocci/archive/2012/06/21/taking-control-of-the-hrd-experience-with-the-new-wif-4-5-tools-with-a-little-help-from-jquery.aspx

Scale Out, Azure Web App などへの対応

もう 1 つ、改善されている点があります。

WIF が作成する cookie は、既定で、そのマシンの user credential や machine credential を使ったデータ保護 (Data Protection) がおこなわれています。

このため、従来は、Windows Azure (2 インスタンス以上) に RP をホストする場合など、複数マシンに Scale out (Scaling) された Web Farm の構成で WIF を使用する際は、マシン間で key が変わってしまい、Sticky Session を使用するか、特別なプログラミングをおこなって対処する必要がありました。(この手法については、Vittorio の こちら のブログの「Sessions and Network Load Balancers」に記載されていますので、ご存じない方は、参照にしてください。)

また、Azure Web App (旧 Azure WebSite) から Azure ACS (Access Control Services) を使う場合にも、App Pool の LoadUserProfile が false に設定されているため、DPAPI (Data Protection API) が適用できず、下図のように System.Security.Cryptography.CryptographicException (The data protection operation was unsuccessful …) のエラーが発生します。

WIF 4.5 では、こうした構成に対し、Web.config に以下の構成変更 (追記) をおこなうことで対処できます。下記の SessionSecurityTokenHandler は WIF が既定で使用するハンドラーであり、この既定のハンドラーを machineKey を使うハンドラーに変更しています。(必要に応じ、Web.config に <machineKey /> 要素を作成し、Farm で共通のキーを設定します。)

. . .<system.identityModel>  <identityConfiguration>    <securityTokenHandlers>      <remove type=        "System.IdentityModel.Tokens.SessionSecurityTokenHandler,         System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>      <add type=        "System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,         System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>    </securityTokenHandlers>. . .  </identityConfiguration>. . .</system.identityModel>. . .

なお、この設定は、Web.config を直接編集しなくても、前述の Identity and Access Tool で [Enable web farm ready cookie] を選択 (チェック) するだけで構成できます。(下図)

ざっとポイントだけ説明しましたが、他にも、いろいろと細かな改善がおこなわれていますので、是非、お試しください。