[FIM2010]製品ロードマップ？

ソースが Directions on Microsoft で、こんなネタが。。（といっても 2011年4月なので古い情報でしょうけど）

既に CY2012 も終わろうとしていますが、Forefront Identity Manager 2012 なんていう話は出てきていないので、R2 のことかも知しれませんね。

誰か Directions on Microsoft のアカウント買ってる人がいらっしゃれば最新情報を！

元スライドはこちら。

Enterprise Software Roadmap for Microsoft Products from Jonathan Daniels

[WAAD]Windows 8 の PowerShell で ServicePrincipal 関連の操作を行う

既出情報ですが、意外と引っかかるのでメモとして書いておきます。

Windows 8 / Windows Server 2012 では Microsoft Online Services Module for PowerShell をインストールして ServicePrincipal 関連のコマンドレット（例えば Get-MsolServicePrincipal）を実行しても ObjectNotFound と言われてしまいます。

これは ServicePrincipal 関連のコマンドレッドが含まれるモジュール（MSOnlineExtended）を実行するのに PowerShell 2.0 のエンジンが必要なためです。※コントロールパネルの Windows の機能から見ると PowerShell 2.0 とありますが実際は Version 3.0 が実行されているからです。（プロンプトから $PSVersionTable を実行すると PSVersion の値が 3.0 となっているが確認できます）

この状態を解消するには、 powershell.exe の引数に -version 2.0 をつけて明示的に Version 2.0 で PowerShell を起動し、MSOnline モジュールおよび MSOnline Extended モジュールをインポートする必要があります。

コマンドプロンプトから以下を実行します。
> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0

PowerShell が起動したら以下を実行します。

PS > Import-Module MSOnline
PS > Import-Module MSOnlineExtended


ただ、副作用があり Windows 8 用の Version 2.0 の PowerShell ISE が用意されていないので、Out-GridView などの機能が使えなくなります。。。
早く PowerShell 3.0 用の MSOnlineExtended モジュールがリリースされないかな。。。

Kerberos 認証の設定を確認する

Forefront Identity Manager 2010 （FIM 2010）に限らず Microsoft の製品群は Active Directory を使った Kerberos 認証を多用しています。
こいつです↓（違

図：ケルベロス（笑）

これは、いわゆる「ダブルホップ」と言われる認証の委任を行うことが多いためです。
※もちろん他の理由もありますが。

ダブルホップを知らない方に向けたおさらいですが、Windows ネットワークの世界での認証は一般に NTLM 認証と Kerberos 認証が利用されます。そして、Windows サーバで構成される Web システムといえば、IIS -> SQL Server での2層構造が主流です。
※ブラウザから IIS へアクセスし、IIS が SQL Server へアクセスするという形でホップが2重になっていることからダブルホップと呼ばれます。

この時、NTLM 認証を使っているとクライアントの資格情報を2段階目のホップ（IIS -> SQL Server）へ引き継ぐ（委任）ことが出来ないため、IIS のアプリケーションプールに指定したアカウントを使って SQL Server へアクセスすることになります。アプリケーションプールに指定したユーザアカウントが SQL Server に対して正しくアクセスできる状況であればこの構成でも問題はありませんが、本来はアクセスしてきたユーザの個人アカウントの権限に基づいて SQL Server にアクセスさせたいところです。

図：NTLM 認証フロー

そこで、SharePoint や FIM 2010 をはじめとする Windows で構成された Web システムでは Kerberos 認証を利用します。Kerberos 認証ではユーザの資格情報を委任することが可能となるため、元々のユーザの資格情報を引き継いでバックエンドのサービスへアクセスできます。

図：Kerberos 認証フロー

尚、ダイアグラム内に出てくる SPN（Service Principal Name）については国井さんの blog の以下のエントリを参照してください。
　Service Principal Name (SPN) について
　
と、ここまでは前段なのですが、SPN や Kerberos の設定って往々にして間違えやすいのと間違っていても場合によっては気が付きにくい、という特性があるので、実際のユーザアクセスの中でちゃんと Kerberos 認証が利用できているのか？を確認する必要があります。

そんな時に有用なのが
　Kerberos Authentication Tester
　http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx
です。

簡単に言うと Web リクエストの中で使われた認証方式や Kerberos 認証で使われた SPN などの情報を出力してくれるツールです。

起動して、Url の欄に FIM Portal のアドレスを入れて [Test] をクリックしてみます。
上手く Kerberos 認証を使うように設定できていれば、Authentication type に Kerberos と表示されるはずです。

また、details のリンクをクリックすると更に細かい情報も表示されます。

SharePoint や FIM 2010 を構築した後にとりあえずこのようなツールを使って確認してみると良いと思います。
また、最近は象クラスタの人からも Kerberos が人気なようなので改めて Kerberos 自体のおさらいをしてみるのも良いかも知れません。

VS2012 用の Identity and Access Tool が RTM

遅ればせながら 10月23日にリリースされた Visual Studio 2012 用の Windows Identity Foundation Tools を試してみます。

まず、機能面の紹介です。
基本的には以前の WIF の Federation Utility と変わりませんが、個人的には下記が大きなポイントだと思います。

１．Identity Provider を ローカル STS、ビジネス Identity Provider（AD FS2.0）、Windows Azure Access Control Service から選択できるようになった。
　　⇒以前は、新しい STS を作成するか、既存の STS を利用するかの選択だった。

２．管理者として Visual Studio を実行しなくても Identity and Access Tool が利用できるようになった。
　　⇒以前は管理者として Visual Studio を実行しないと Federation Utility が実行できなかった。

３．ACS 側の設定を自動的に作成してくれるようになった。
　　⇒以前は ACS 上に RP の作成およびクレーム・ルールの作成を手動で行う必要があった。

４．認証されていないリクエストに対するアクションを選択できるようになった。
　　⇒以前は単純に STS にリダイレクトするだけだったが、今回から加えて controller を生成することが出来るようになった。


特に3番目、4番目については開発者にとって非常に有用な機能なのではないでしょうか？


では、早速試してみます。

■モジュールのダウンロードとインストール
　モジュールは vsix 形式で提供されていますので、ダウンロード、実行すると Visual Studio の拡張機能が有効になります。

　Identity and Access Tool のダウンロード URL
　　http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e


■プロジェクトの作成
　Controller の自動生成を試してみたいので、今回は MVC4 のプロジェクトを作ってみます。もちろん Visual Studio は管理者で実行しなくても大丈夫です。

　テンプレートから web -> ASP.NET MVC 4 Web アプリケーションを選択し、適当な名前を付けてプロジェクトを作成します。

　OK をクリックするとプロジェクト テンプレートの選択画面が出てきますが、デフォルトで選択されている[インターネット アプリケーション]を選んだまま OK をクリックします。

■Identity and Access Tool の設定
　プロジェクトの作成が終わったら、ソリューションエクスプローラからプロジェクト名を右クリックして表示される[Identity and Access]を開きます。

　Choose where your users are from でどの STS を使うのか選択できます。今回は ACS の自動設定を試してみたいので、[Use the Windows Azure Access Control Service]を選択します。
　すると、Select one or more providers from the ones configured in the ACS Namespace: で使用する ACS の Namespace の設定を行うリンクが表示されるので、クリックします。

　Configure ACS namespace のダイアログが表示されるので、ACS namespace および management key を入力します。

　ここで設定する management key は ACS の管理ポータルの管理サービスのパスワードです。

　設定が完了し、ダイアログを閉じると ACS 上に設定されている IdP 一覧が取得されて表示されるので、このアプリケーションで利用したい IdP を選択し、一旦 OK をクリックし Identity and Access Tool を閉じます。

　ちなみに、このとき ACS 管理ポータルを見ると 証明書利用者アプリケーションとして作成したアプリケーションが登録されていることがわかります。

　同様に規則グループも自動生成されます。内容は単なるパススルーなので、必要に応じて編集をしてあげる必要はあります。

■Controller の自動生成
　次は、これまた新機能である Controller の自動生成を試します。
　再び Identity and Access Tool を起動し、今度は[Configuration]タブを開きます。
　すると、Choose how to handle unauthenticated requests という項目があるので、[Generate a controller in your project to handle the authentication experience at the following address]を選択します。

　これで、認証されていないリクエストに対応する Controller が生成されましたので、実際に認証が必要なリクエストを行うように設定を行います。
　今回はデフォルトの About 画面を認証が必要な画面として定義してみます。
　方法は簡単で、HomeController.cs の About() に対して [Authorize] を追加するだけです。

■アプリケーションの実行
　では、F5 キーを押して実際にアプリケーションを実行してみます。

　起動してきたら[バージョン情報]をクリックします。

　すると、ログインページが表示されます。ホームレルム ディスカバリ先として、先ほど ACS から取得してきた IdP 一覧が表示されるのがわかります。

　今回は Google を選択してみます。Google アカウントへリダイレクトされ、Account Chooser が表示されるので、使いたいアカウントをクリックします。

　認証が終わると、ホーム画面へ戻り、ユーザ名が取得できているのがわかります。

いかがだったでしょうか？非常に単純なサンプルだったので実際は色々とカスタマイズが必要にはなるでしょうが、ほぼノンコードでここまで出来るようになっている、という意味で以前のツールに比べてもかなりの進化を遂げていることがわかります。
ACS を使って多くの外部 IdP ユーザを対象にしたアプリケーションを簡単に開発できるので、EC サイトなど B2C シナリオではかなり有用な機能になるのではないかと思います。