Windows Identity Foundation と ACS 用の新ツール ～ クラウドカバー Episode 72
今回のクラウドカバーは、Admiral Identity (アイデンティティ提督)こと、Vittorio を迎え、Windows Identity Foundation (略称 WIF。”ウィフ” と発音）に関するお話し。
なお、今回紹介する WIF は現在開発中の .NET Framework 4.5 用のもので、このバージョンから名前空間が Microsoft.IdentiryModel ではなく、System.IdentityModel に変更される（よりメジャーな存在になる、ってことですね）とのこと。
これで、ACS / WIF 統合なアプリを Windows Azure にデプロイした後に、Microsoft.IdentityModel の DLL を配置するのを忘れていて、再デプロイ、、、、ということがなくなりそうですね :-)
いつものようにニュースから。
◆ Updated Release of Windows Azure Toolkit for Windows 8 Consumer Preview
Windows 8 の Consumer Preview のリリースに合わせてアップデートされた Windows Azure のツールキットです。
なお、現在 Windows Azure SDK 自体は、Visual Stiudio 11 に対応していないため、Windows 8 のメトロアプリケーションに関しては Visual Studio 11 で開発していただき、サーバー部分(Windows Azure) は、Visual Studio 2010 + Azure SDK 1.6 の環境で開発いただくような形になります。
Windows Azure Storage の機能である Queue（キュー）を使用する際の初めの一歩的な内容から、実際に信頼性が求められるシステムにおいてどのように活用するか、までを綴った大作 Blog エントリー。
後半には、Windows Azure Service Bus の Queue との機能比較もありますので、Queue の使用を検討されている方はぜひご参照ください。
◆ Importance of Affinity Groups in Windows Azure
Windows Azure において、ホステッド サービスやストレージ サービスを新規申し込む際に選択（あるいは作成）可能な Affinity(アフィニティ)グループ。
Affinity グループは、これから利用しようとしているホステッド サービスや、ストレージ サービスを極力近くに配置してね、と、Widnows Azure のデータセンター（の Fabric Controller) に伝えるための手段です。
この Blog エントリーでは、Affinity グループの重要性についてと、あとから Affinity グループを設定（あるいは変更）することができないので、きちんと考えて設定しようね、というお話が書かれています。
◆ Windows Azure PowerShell Cmdlets 2.2.2 Release
最後のニュースは PowerShell Cmdlets(コマンドレット）のアップデートについて。
コマンドで Windows Azure のサブスクリプション情報の管理から、パッケージの配置、など様々な操作が可能になる Cmdlet。
パワーシェル ユーザーの方は是非お試しください。
では、いよいよ本日の本題。
もともと、Camptain Identity と呼ばれ、Identity 技術のエバンジェリストとして活躍していた Vittorio ですが、現在は製品開発のチームにて、WIF の開発に携わっています。
そして今回彼が紹介するのは、WIF の最新版。この最新版においては Visual Stusio 11 と .NET Framework 4.5 をターゲットにしており、現在の Visual Studio 2010 および .NET Framework 4.0 環境とは異なり、.NET Framework 本体の機能として WIF の機能が提供されています（これまでは、追加でランタイムをインストールしていました）。
では、早速 Windows 8 にインストールされている Visual Studio 11 を立ち上げてみましょう。
まずは、Visual Studio 11 にて、Web アプリケーションの新規作成を行います。そしてソリューションエクスプローラーで作成されたプロジェクトの項目上で右クリックを押し、表示されたメニューから ”Identity and Access…” を選択します。（残念ながら Visual Web Developer 11 Express にはこのメニューはないようです）。
この部分、Visual Studio 2010 + 既存の WIF ツールの環境だと、 ”Add STS Reference…” といったように、あらかじめ用意しておいた STS(Secure Token Service)の情報を渡すようになっていました。
今回の Visual Studio 11 + WIF ツールでは、 ”Identity and Access…” と、より抽象化されたメニュー（機能）になっていますね。
実際にメニューを選択すると、以下のようなウィザードが立ち上がります。
Wade としては、最初のテスト用の Local STS の機能がいいね！、としびれたようです。
実際にデバッグ実行で、ローカルの Windows Azure エミュレーターを使ってアプリケーションを動作させると、Local STS も一緒に動作を始めます。
また、ローカルの STS を使用する際に、セキュリティ トークンのフォーマットをどうするか、あるいはクレームに含むべき情報をどのようにするか（スキーマ、および値）は、ウィザードにて設定可能です。
また、これまでは Web.config で直接編集していた Realm や Audience といった情報もウィザードから扱えるようになっています。
また、認証を受けていないリクエストに関して、すべて STS にリダイレクトするのか、それとも一旦別ページにリダイレクトするのかの設定も可能になっています。
最後の “Enable web farm ready cookies” は、新しい WIF で追加になるクッキーの暗号化機能を Web Farm でも使用できるようにするためのチェックボックス。この機能では、マシンキーを使ったクッキーの暗号化を行います(Windows Azure では、複数のインスタンスを使用する場合でも共通のマシンキーを使用します）。
さて、このウィザード、最初の選択で Windows Azure の ACS を選ぶと、ACS の設定用の項目が表示されます。
現在の Visual Studio 2010 + WIF の環境では、この設定は Windows Azure の管理ポータルにおいて、ACS 設定用の画面を呼び出し、Identity Provider の設定として実施していた項目です。また、Realm 情報等は、Relaying Party の設定として、先に出ていたセキュリティトークンの情報は Rule の設定として実施していた項目です。
参考までに下記が ACS の設定を行うポータル画面です。
このあたりが、Visual Studio に統合され、より簡単に設定が可能になった、という事ですね。
なお ACS の機能自体が変わったわけではないので、Visual Studio での設定後、より細かな設定はポータルで行う、ということももちろん可能です。
さて、Vittorio がウィザードにて実際に Google と Facebook を選択し、デバッグ実行したのが下記の画面。ACS によって、Identity Provider の選択画面にリダイレクトされます。
Facebook のボタンをクリックして、認証情報をアプリケーションに渡すと、先ほど作成していた Web アプリケーションにリダイレクトされ、認証情報に含まれていたユーザー名も表示されます。
ということで、これまでも簡単に設定できていた認証機能が、より簡単にアプリケーションに統合できるようになる Visual Studio 11 と 新しい WIF。
ぜひお試しください♪
そして、最後は恒例の Tip of the week!
今回の Tips は、ニュースで2つ目に紹介した「Everything you need to know about Windows Azure queue storage to build disconnected and reliable systems」から。
Windows Azure Storage の Queue を使用する際には、Queue に情報があるかどうかを確認するためのトランザクションが発生します。また、この確認のためのアクセスに関しても、課金が行われます（1万回のトランザクションで 0.88円）。
Queue に対する確認頻度が低ければ、課金も少なく、また情報確認のアクセスに伴う Queue 自体のレスポンス悪化も抑えることができますが、Queue のタイムリーな情報確認ができなくなります。
一方で確認を頻繁に行えばタイムリーな情報確認ができますが、情報確認のためのアクセス伴う Queue のレスポンス悪化や、課金額の増加が発生してしまいます。
今回のブログで紹介されているアイディアは、Queue に情報が残っている際は連続して Queue への情報確認を行い、Queue に情報がない状態が続いている場合は徐々に情報確認の頻度を下げる（インターバルを長くする）というもの。
実際には、構築するアプリケーションにおける Queue の使用パターンに基づいて最適なアルゴリズムを構築するのが良いと思われますが、ひとつのアイディアとして参考になるかと。
ということで、今回のクラウドカバー紹介は終了です。
それでは！