FIMパスワードリセットのアーキテクチャの紹介

おさらいになりますがFIMの全体アーキテクチャは下図のようになっています。
















FIMがMIIS/ILMと大きく違う点は、IdMプラットフォームとしてWebサービス基盤であるFIM Serviceが新たに追加されたことです。
このことにより、WS-*の標準的なプロトコルでのやり取りが可能になり、FIM PortalはもちろんOutLookをはじめ、今回のテーマであるパスワードリセットなどクライアントソリューションに幅が広がりました。

さて、本題ですがFIMにはWindowsログオンに統合されたパスワードリセット機能があります。他のIdM製品やアクセス管理製品にもパスワードリセット／リマインド機能をもつものも多数存在しますが、現実的には特に企業における導入が中々進んでいない状態です。
これは、企業でIdMを導入する際に当然情報システムへの入り口となるWindowsログオン（たいていはActive Directory）のアカウントのライフサイクルも管理することになるのですが、いざIDやパスワードを忘れた、となってもそもそもPCにログオンできなければブラウザが開けないのでパスワードリマインダ画面へ到達できなかったり、メールも見ることができないので新しいパスワードの通知も出来ない、という状態に陥るためです。
これを回避するために、パスワードリセット画面しか開けないようにグループポリシーで厳密に管理されたヘルプデスクユーザをドメイン上に用意しておいて、無理やりセルフリセットを行う、などという工夫が必要になってきてしまいます。

その点、FIMではクライアントモジュールのインストールは必要ですが、パスワードリセット機能がWindowsログオン画面にプラグインされているので、パスワードを忘れたときWindowsにログオンできなくてもあらかじめ設定した秘密の質問に答えられればパスワードのリセットが可能です。

実装の方法の解説などはそのうち紹介しようかと思いますが、今回はどうやってこのモジュールが動いているのか？について仕組みを解説したいと思います。

下の図がパスワードリセット時のメッセージの流れの全体像です。

順番に解説していきます。

まず、関連するFIMのモジュールと役割は下記の通りです。

区分	名称	役割／概要
FIM Client	Gate Framework	LogonUIへのプラグイン（XP以前でいうところのカスタムGINA）。 Password Proxyを経由してFIM Serviceと通信する。 アンマネージドコードで書かれたモジュール。
	Password Proxy	FIM Serviceと実際のやり取りを行うWebサービスクライアント。 マネージドコードで書かれたモジュール。
FIM Service	[MPR]Anonymous users can reset their password	パスワードリセット要求があった際に呼び出されるMPR（Managed Policy Rule）。 認証ワークフローのPassword Reset AuthN WorkflowとアクションワークフローのPassword Reset Action Workflowが設定されている。
	[AuthN WF]Password Reset AuthN Workflow	パスワードリセットを実行する前に実施される認証ワークフロー。 Active Directoryによる認証、ロックアウトゲート、QAゲートが含まれる。
	[Action WF]Password Reset Action Workflow	実際にパスワードをリセットするためのアクションワークフロー。 WMI経由でFIM Synchronization ServiceのAD MAを呼び出す。
FIM Synchronization Service	AD MA（Active Directory MA）	実際にActive Directoryのパスワード属性を変更する。

次に実際にパスワードリセットが行われる際のシーケンスは下記の通りです。

項番	モジュール	動作概要
1	Gate Framework	ユーザからのパスワードリセット要求を受けてPassword Proxyを呼び出す
2	Password Proxy	FIM Serviceに対して「User.ResetPassword」属性の変更を要求する
3	FIM Service	項番2をトリガーにMPR「Anonymous users can reset their password」を呼び出す。（Anonymousで呼び出す）
4	Password Reset AuthN Workflow	Anonymousでの呼び出しなので認証失敗となり、AuthNRequestFaultを返却する。この際、FIM ServiceのSTS（Security Token Service）のエンドポイントアドレスを返却する。
5	Password Proxy	FIM ServiceのSTSへ入力されたユーザ名を渡す。
6	FIM Service STS	当該ユーザに設定されている質問リストを返却する。
7	Password Proxy	Gate Frameworkを経由してLogonUIに質問リストを表示する。
8	Gate Framework	ユーザが入力した質問への回答をPassword Proxyへ渡す
9	Password Proxy	FIM ServiceのSTSへ入力された質問への回答を渡す。
10	FIM Service STS	回答があっていれば、セキュリティトークンを発行する
11	Password Proxy	MPRへ取得したセキュリティトークンを渡し、ワークフローの実行が継続される。
12	Password Reset Action Workflow	新しいパスワードを使い、WMI経由でFIM Synchronization ServiceのSetPasswordを呼び出す。（FIM Service Accountユーザの権限）
13	Active Directory MA	Active Directory上の当該ユーザのパスワード属性をリセットする。（AD MAに設定されたユーザの権限）

この通り、それなりに複雑な手順を踏んでパスワードがリセットされることを鑑み、
・FIM Serviceの冗長化（可用性の維持、パフォーマンスの考慮）
・FIM Synchronization Serviceの冗長化（MIIS/ILMの頃のように一日一回のバッチ処理専用サーバではなくなっていることを意識）
を考慮したサイジング、トポロジ設計が必要になります。
※当然のことですが、AD MAは絶対に作成することも必要。

フロント（クライアントからの要求を処理するため）のFIM Serviceとバッチ処理に対応するためのFIM Serviceを分離することも可能なので、またシステム構成の考え方と対応する実装方法についてはご紹介したいと思います。

ちなみに、今回のエントリを含めFIMのSSPR（Self Service Password Reset）に関してはAnthony Ho氏のblogが詳しいです。