ADFS2.0 ＆ WIF on AzureでオンプレミスとクラウドのSSO その1

エンタープライズ分野へのクラウド適用のキモはオンプレミスとクラウドの統合、という話がまことしやかに騒がれていますね。Azureに関してはAppFablicの実装が煮詰まってくればそのあたりの実現イメージもより湧いてくるのかも知れません。

とはいえ、まだAppFablicは未だCTPで、.NET Access Control ServiceでのSTS（Security Token Service）指定周りの仕様も柔らかい状態っぽいので、今出来ることという意味でAzure上でWIF（Windows Identity Foundation）＋ADFS2.0の環境を動かしてみました。

また、同様にオンプレミスアプリケーションとしてWIF＋ADFS2.0の環境を作り、結果的にオンプレミスアプリケーションとAzure上のアプリケーションのPassive FederationでのSSOが出来るような環境を作ってみます。















結果として、STS（ADFS2.0）で認証され、















オンプレミスアプリケーションにアクセスした状態で
















そのまま（認証なしで）Azure上のアプリケーションへアクセスします。


















少々長くなるので、下記のような構成でお送りいたします。

１．環境の準備
　　今回用意した環境と各コンポーネントのセットアップ方法の解説を行います。

２．オンプレミスのアプリケーションを作成・発行する
　　以前も一部解説しましたが、WIFがRCになって一部コードも変更になりましたので、改めてコードの解説をします。

３．Azure上のアプリケーションを作成・発行する
　　基本的にオンプレミスのアプリケーションと同一コードで動きますが、Azure上での動作ならではの設定がありますので、そのあたりを重点的に解説します。
　　また、Windows Azure Hosted Serviceに関する設定やデプロイについても解説します。

４．シングルサインオンしてみる
　　作成した環境で実際に同じセキュリティトークンを使ったシングルサインオンが出来ることを確認します。



ということで今回は「１．環境の準備」をお送りします。

◆環境概要
今回用意したのは下記の2台のマシン（仮想マシン）です。

サーバ	役割	OS	ミドルウェア	備考
STSサーバ	認証、セキュリティトークンの発行を行う	Windows Server 2008 R2	ADFS2.0 RC	ドメインコントローラも兼ねる
オンプレミスアプリケーションサーバ	オンプレミスアプリケーションをホストする	Windows 7 Ultimate(x64)	・IIS ・Visual Studio 2008 Standard Edition SP1 ・Windows Identity Foundation 1.0 ・Windows Identity Foundation SDK ・Identity Developer Training Kit(PDC2009) ・Windows Azure Tools for Microsoft Visual Studio (November 2009)	開発環境も兼ねる

◆STSサーバのセットアップ

下記の流れでセットアップを行います。（Geneva Serverに比べて大分楽になりました）
１．OSのインストール
２．ADDSの役割追加
　　※DNSは自動で追加
３．ADFSのインストール
　　※WIF、IIS、PowerShellは自動で追加
４．IISで自己証明書の発行
５．ADFSのIdP設定

※ちなみにWIFおよびADFS2.0は更新プログラムとしてインストールされます。
　WIF：KB974405
　ADFS2.0：KB974408
※ADFS2.0からSQL Serverを使わずにWindows Internal Databaseをレポジトリに使うことが出来るようになりました。（デフォルトはWindows Internal Databse）


では、具体的な手順です。

１．OSのインストール
２．ADDSの役割追加
　　※DNSは自動で追加

このあたりはいつも通りで。ちなみに今回の環境は、
　ドメイン名：eidentity.local
　ドメインコントローラ名：ADFS20.eidentity.local
です。

３．ADFSのインストール

インストーラを実行すると、自動的に必要な環境（IISやPowerShell、Windows Internal Database）を含め整備されます。
インストール時に選択する項目は「Server Role」のみで、Federation serverとしてセットアップするか、Federation server proxyとしてセットアップするかを選択します。今回はFederation serverとしてセットアップします。


















インストールが完了するとADFSの管理コンソールが起動してきますが、実際の設定に入る前にIIS管理コンソールで自己証明書を作成して構成しておく必要があります。
今回は「adfs20.eidentity.local」というフレンドリ名で作成しています。















次にADFSのサーバ設定を実行します。
管理コンソールから「ADFS2.0 Federation Server Configuration Wizard」を実行します。
















以下の値を設定／選択します。

ステップ	選択する値	備考
Welcome	Create a new Federation Service	今回は既存のファームへの追加ではなく新規でサーバを構成します。
Select Deployment Type	Stand-alone federation Server	ADFS2.0からサーバファームを構成することが出来ますが、今回は単体で構成します。
Federation Service Name	SSL certificateおよびFederation Service nameに先ほど作成した自己証明書を設定（一つしかインストールされていないので選択不可）

設定が完了するとRelying partyの設定を要求されますが、これはアプリケーションを作ってから設定するのでこの段階では放置しておきます。

◆オンプレミスアプリケーションサーバ（兼開発環境）のセットアップ

下記の流れでセットアップを行います。
１．OSのインストール
　　ドメインへの参加およびIISの役割追加を行います。
２．Visual Studio 2008、SP1のインストール
　　C#、VB.NET、Web開発のインストールを行います。
３．WIF、WIF SDKのインストール
４．Identity Developer Training Kit(PDC2009)のインストール
　　Azure上へデプロイする際の証明書を作成するのにネイティブ暗号化API（CAPICOM）を使います。もちろん単独でCAPICOMをダウンロードして手動で作成しても良いのですが、Training Kitにバッチファイルがあるのでそれを流用しました。
５．Windows Azure Tools for Microsoft Visual Studio (November 2009)のインストール

ただ、こちらはこの段階で特に込み入った設定をする必要もないので、順番にインストールをしていきます。


とりあえずここまででローカルに必要な環境は揃いましたので、次回はまずオンプレミスのWIF/ADFS連携のクレームベースのWebアプリケーションを作成します。

FIM2010のパフォーマンス その３

前回からしばらく間があいてしまいましたが、紹介した環境下でのFIMの各構成要素毎のパフォーマンス測定結果およびボトルネックの考慮に関する情報です。
また、後半ではFIMのサイジングに関する考慮点を紹介します。

参考情報
・各サービスのリソース使用状況
http://blogs.msdn.com/darrylru/archive/2009/10/09/fim-2010-performance-testing-hardware.aspx
・FIMのサイジング
http://blogs.msdn.com/darrylru/archive/2009/10/22/fim-2010-performance-testing-scale-load.aspx

■各構成要素毎のパフォーマンス測定結果
◆Synchronization Service
・概要
　基本的にディスクの性能がすべてです。

・Synchronization Serviceによるリソース使用状況
　Synchronization Serviceが動く際のリソースの使用状況のカウンタです。Fドライブ（SQL Serverのデータ領域）へのアクセスが際立ちます。一部振りきってしまっている部分もあるので、結果的にこの部分がボトルネックになるということだと思います。













◆FIM Service
・概要
　やはりこちらもSQL Serverがキーポイントになりますが、こちらは主にSQLのクエリ処理が中心となるのでディスクに加えてメモリサイズやCPU性能が効いてきます。（都度SQL Serverに問い合わせに行くので大量のSQLトランザクションが発生しているはず）

・FIM Serviceによるリソース使用状況
　FIM Serviceが動く際のリソースの使用状況のカウンタです。メモリおよびFドライブ（SQL Serverのデータ領域）へのアクセスが際立ちます。一部振りきってしまっている部分もあるので、結果的にこの部分がボトルネックになるということだと思います。














　更に、このケースではFIM ServiceとSQL Serverの同居構成なので各サービス毎のCPUの使用状況を深堀りしてみます。















黒色でハイライトされているのがSQL ServerによるCPUの使用なので、このグラフからも主にSQL Serverに対して多くのリソースの割り当てを行うことが重要だということが読みれます。


■サイジングに関する考察
どのくらいのユーザ数ならこんなトポロジやこの程度のマシン性能、といったバシっとした情報が紹介されているわけではありませんが、FIMを導入するうえで規模（スケール）と負荷（ロード）について考慮すべきポイントが紹介されています。

◆規模（スケール）
　FIMを含め基本的に各IdM製品について言えることですが、どれだけのオブジェクトをハンドリングする必要があるのか？が最大のポイントになります。ということで、FIMでは何をするとオブジェクトの数が変動するのか？についての考察が重要になります。

　まず、ポータルの導入によるエンドユーザに対するオブジェクト管理権限の委譲が最大のポイントとなります。委譲する範囲によっては実際の人事上の従業員や組織数を大幅に上回る数のオブジェクトを管理する結果となることも考えられます。実際マイクロソフトにおいては150,000以上のユーザと400,000以上のグループを使用しているそうです。まだ同時にこの問題はIdMだけでなくレポジトリ（Active DirectoryやLDAPなど）のサイジングにも影響を及ぼす問題なので十分に考慮が必要ということが出来ます。

　次に、これはグループオブジェクト（およびメンバシップ）とFIMが内部で管理するSETオブジェクトの数に関連する問題ですが、例えばユーザの属性値を基準としたダイナミックなグルーピングを行うかどうか、行うとしたらどのような種類および数になるのか、について十分な検討が必要となります。

　また、コンピュータオブジェクトなどのカスタムオブジェクトの管理の有無についてもオブジェクト数の算出に大きく影響を与えます。

　最後にFIMが内部で使用するポリシーオブジェクト（MPRやActionFlow）についても考慮が必要です。コードレスプロビジョニングを使うことによりそれ自体がFIM上のオブジェクトである（つまり、ILMSDBとの同期対象となる）ERE（Expected Rules Entry）やDRE（Detected Rules Entry）が作成されるので、それらのオブジェクトをハンドリングするオーバーヘッドについても考慮が必要となります。

　まとめると、以下の点について事前に十分考慮し、実際に管理する対象オブジェクトの数を算出することが必要となります。
　・エンドユーザへの権限委譲
　・ダイナミックグルーピング
　・カスタムオブジェクト
　・ポリシーオブジェクト


◆負荷（ロード）
　IdMシステムの規模感が判明した後は各コンポーネントに対してどの程度の負荷がかかるのかの算定が必要になります。負荷は発生しえるトランザクションの種類と数から算出することになりますので、ここではFIMに対してどのようなトランザクションが発生しえるのか？について確認して行きます。

　具体的には下記の種類のトランザクション（オペレーション）の数を定義することが必要であると記載されています。
・グループへの参加登録や登録解除リクエスト
・スタティックもしくはダイナミックグループの作成リクエスト
・セキュリティグループと配布グループの内訳
・パスワードリセットのための事前登録やパスワードリセットのリクエスト
・FIMクライアントがインストールされているコンピュータの数（クライアントは定期的にログオン時に登録が必要かどうかをチェックするため）
・ユーザがグループ管理を行う際に主としてポータルを使うか、Outlookを使うか？（Outlookを使う場合メールを経由するため、Exchangeサーバへのポーリングを行うメールリスナーへの負荷を考慮する必要があるため）
・企業内の利用パターン（ログインのピーク時間帯とピーク時の集中率）

　これらの事項について確認し、VSTSなどを使って負荷試験をして実際に使用する各ハードウェアのスペックなどを決定していく、ということになります。

新年のご挨拶＆MVPアワード受賞しました！

既に新年明けて3日目に突入してしまいましたので遅ればせながら、ということになりますが皆さん明けましておめでとうございます。

お陰様で本Blogを初めてから2度目の新年を迎えることが出来ました。色々とやりかけのテーマなどを残したままになっている点があるので是非今年はそのあたりも含め更に内容の充実を図っていきたいと思います。
また、2010年はForefront Identity Manager 2010やADFS2.0の正式リリースやAzure関連の拡充（特に.NET Access Contorol Services改めAppFablicでのクラウド／オンプレミス連携など）を含め話題が尽きない1年になるのでは、と思っていますので頑張って情報のキャッチアップをして有用なネタをご提供できれば、と思っています。


そんな中、新年早々にIdentity Lifecycle Manager分野でのMVP（Microsoft Most Valuable Professional）アワード受賞のメールを頂きました。こちらも日頃アクセスしてくださっている皆様のお陰だと思い、非常に感謝しております。

同じカテゴリのMVPホルダーでプロフィールが公開されている人を見ても現状11人しかいなさそう（しかもほとんどの人がTechnet Forumで見る人ばっかり）、且つ日本人はゼロっぽいので頑張って今後も活動していきたいと思います。


何はともあれ、本年もよろしくお願い致します！

ADFS2.0 RCリリース

12/18にリリースされていました。


アップデート内容ですが、"Geneva" Team Blogによると、下記の通りです。

・SAML 2.0 protocol support for Identity Provider Lite, Service Provider Lite and the eGov 1.5 Profile verified by Liberty Interoperable SAML 2.0 interoperability testing

→以前お知らせしたようにLibertyのSAML2.0相互運用性にパスしています。

・Simplified user experience for configuring high availability federation server farm and proxy deployments

→冗長構成のフェデレーションサーバファームとProxyのデプロイが簡単に。

・Automatic encryption and signing certificate distribution and rollover across a farm of multiple federation servers, enabling zero touch management of trust relationships

→自動暗号化、証明書配布署名、複数のフェデレーションサーバから構成されるファーム間のロールオーバー、操作なしでの信頼関係構成

・Choice of deploying without SQL Server for storing AD FS 2.0 configuration data

→ADFS2.0の構成データストア用のSQL Serverなしでのデプロイが可能に

・Claims based authorization rules for restricting security token issuance

→制限されたセキュリティトークン発行の為のクレイムベース認可ルール

・Improved events, audits, and tracing for diagnostics

→診断のためのイベント、監査、トレースの増強

・Complete PowerShell support for end to end AD FS 2.0 management

→ADFS2.0の管理をするためのPowerShellの完全サポート

・Lots of other fixes and UI improvements!

→その他多数の修正とUIの改善


また、同時に以下のモジュールもリリースされています。
・Microsoft Federation Extensions for SharePoint 3.0 RC
・Windows CardSpace 2.0 Beta 2 Refresh

例によってVMイメージ（VHD）もあわせてダウンロード可能なので、環境をお持ちの方はそちらが手軽かも知れません。（私はHyper-V環境を持っていないのでゼロからの構築になりますが・・・）

安全なクラウド・コンピューティングの実現に向けたガイドライン

CSA(Cloud Security Alliance)が12/17にSecurity Guidance for Critical Areas of Focus in Cloud Computing V2.1をリリースしています。

ガイドラインによるとクラウドコンピューティングの定義は、
1)オンデマンドかつセルフサービス方式で利用されるようになっていること
2)ネットワーク経由でさまざまな場所からアクセスできること
3)共有コンピューティング・リソース・プールからリソースが提供されること
4)必要に応じて利用規模を迅速に拡大、縮小できること
5)何らかの方法で使用量が測定されること
だそうです。

また、クラウド環境におけるセキュリティを下記の13の領域（ドメイン）に分割してそれぞれに関する指針が提示されています。

1)Cloud Computing Architectural Framework
2)Governance and Enterprise Risk Management
3)Legal and Electronic Discovery
4)Compliance and Audit
5)Information Lifecycle Management
6)Portability and Interoperability
7)Traditional Security, Business Continuity, and Disaster Recovery
8)Data Center Operations
9)Incident Response, Notification, and Remediation
10)Application Security
11)Encryption and Key Management
12)Identity and Access Management
13)Virtualization


その中で12番目に来ている「アイデンティティ＆アクセス管理」についてざくっと紹介しておきます。

ガイドラインによるとアイデンティティ＆アクセス管理を以下の4つの主要な機能に分けています。
・アイデンティティプロビジョニング／デプロビジョニング
・認証（Authentication）
・連携（Federation）
・認可（Authorization）／ユーザプロファイル管理


資料ではそれぞれの機能領域について以下のように解説をしています。

◆アイデンティティプロビジョニング
クラウドコンピューティングサービスを採用する組織にとって主要なチャレンジのひとつはクラウドへのユーザのセキュアかつタイムリーなプロビジョニングとデプロビジョニングである。その上、企業内のユーザ管理プロセスに投資をしてきた企業はそれらのプロセスと経験をクラウドサービスに拡張／展開しようとするであろう。

◆認証（Authentication）
企業がクラウドサービスを活用し始める再、信頼でき、管理できる方法でのユーザ認証は重大な要求である。企業はクレデンシャル管理、マルチファクター認証等の強度の高い認証、委任された認証、すべての種類のクラウドサービスに渡る信頼の管理の様な認証に関連する取り組みを行う必要がある。

◆連携（Federation）
クラウドコンピューティング環境においてはアイデンティtフェデレーション（Federated Identity Management）は、企業がその企業が選択したアイデンティティプロバイダを使用してクラウドサービスのユーザ認証を行う上で、重大な役割を演じる。その中で、サービスプロバイダとアイデンティティプロバイダの間でID属性を安全な方法で交換することは重要な要求である。クラウド内でアイデンティティフェデレーションを考える企業は、サポートされる範囲において、アイデンティティライフサイクル管理や信頼性・完全性を守るあらゆる認証方式を兼ね備える様々なチャレンジやソリューションを理解すべきである。

◆認可／ユーザプロファイル管理
ユーザプロファイルとアクセスコントロールポリシーに対する要求は対象となるユーザがコンシューマの様に個人なのか、従業員や学校や医療機関など企業に所属しているのかによって様々である。SPI環境（※）におけるアクセスコントロールは、クラウドサービスへのアクセスをコントロールし、監査可能な方法で実行する為に使用するユーザプロファイルとポリシー情報の信頼関係を構築することを含む。

※SPI：以下の頭文字
　Software as a Service
　Platform as a Service
　Infrastructure as a Service


また、その上で各機能に対する推奨ポイントを以下のようにまとめています。

◆アイデンティティプロビジョニングに関する推奨
・クラウドプロバイダによって提供されるケイパビリティは現在の企業の要求には適切とは言えない。カスタマーは管理の複雑性を増大させるクラウドプロバイダに特化したカスタムコネクタを開発する様なプロプライエタリなソリューションを避けるべきである。
・カスタマーはクラウドプロバイダによって提供される実用的で（望ましくはSPMLスキーマに則った）標準的なコネクタを利用すべきである。もしクラウドプロバイダが現在SPMLに対応していないのであれば、対応するように要求すべきである。
・クラウドカスタマーは自身の信頼できるアイデンティティ情報レポジトリをクラウドのアプリケーションとプロセスに対応できるように修正もしくは拡張すべきである。

◆認証（Authentication）に関する推奨
クラウドプロバイダとカスタマ企業は両者ともクレデンシャル管理、強固な認証に関して適切にリスクを低減させる費用対効果の良いソリューションで実現させるべきである。

SaaSおよびPaaSプロバイダは彼らのアプリケーションやプラットフォームにアクセスする為のビルトインの認証サービスもしくは企業に認証を委任する為のサービスを提供している。カスタマへは認証方式について以下の選択肢が提供される。
・企業向けの認証。企業はユーザ認証をフェデレーションによってSaaSベンダと信頼関係が構築された企業自身のアイデンティティプロバイダを経由して実施する。
・個人ユーザ向けの認証。企業は複数のサイトにおいて単一のクレデンシャルセットの利用を可能にするGoogleやYahoo,OpenID、LiveIDなどのユーザセントリック認証を利用する。
・認証委任する為のプロプライエタリな方式を要求するSaaSプロバイダは継続する前に適切なセキュリティ検証がなされているかを徹底的に検証されるべきである。一般的にはオープンスタンダードを利用すべきである。

IaaSについては認証戦略は企業における既存環境を利用できる。
・IT要員については既存のシステムと手続きを利用できるので、VPNの確立が良いと思われる。
・いくつかのソリューションは企業ネットワークとのVPNトンネルを作成する、もしくは連携させることが可能である。VPNトンネルはSSOやLDAPベースの認証システムなど既存のアイデンティティ管理システムをアプリケーションが利用するような場合に有効である。
・VPNトンネルが使えないような場合はアプリケーションはSSLの様なネットワークの暗号化とともに様々なフォーマット（SAMLやWS-Federationなど）の認証アサーションに対応する様に設計されるべきである。このアプローチは企業に対し、企業内だけでなくクラウドについてもSSO連携（Federated SSO）が可能にする。
・OpenIDはアプリケーションが企業ユーザを超えて使われる場合における別の選択肢である。しかしながら、OpenIDのクレデンシャルのコントロールは企業の外部にあるので、そのようなユーザに対するアクセス権限は適切に制限されるべきである。
・クラウドプロバイダによって提供されるローカル認証サービスはOATHに準拠すべきである。OATHに準拠したソリューションであれば、企業は単一ベンダーの認証クレデンシャルに固定されることを避けることができる。
・（テクノロジーに関係なく）強固な認証を有効にするためにクラウドアプリケーションは企業にSAMLで認証を委任する機能をサポートすべきである。
・クラウドプロバイダはワンタイムパスワードやバイオメトリクス、デジタル証明書、ケルベロスなど様々な強固な認証オプションを提供することを考えるべきである。このことは企業に対して彼らの既存インフラの利用についての別の選択肢を提供する。

◆連携（Federation）に関する推奨
クラウドコンピューティング環境においてアイデンティティの連携は、連携した企業に認証、シングルサインオン、サービスプロバイダとアイデンティティプロバイダの間での属性交換を有効にする為の主要な要素である。クラウド内でアイデンティティフェデレーションを考える企業は、サポートされる範囲において、アイデンティティライフサイクル管理や信頼性・完全性を守るあらゆる認証方式を兼ね備える様々なチャレンジやソリューションを理解すべきである。
・クラウドプロバイダを探している企業はそのプロバイダが最低でも一つの標準（SAML、WS-Federation）をサポートしていることを確認すべきである。SAMLは主要なSaaS、PaaSクラウドプロバイダによって広くサポートされているフェデレーション標準である。複数の標準をサポートすることは柔軟性を増すことを可能にする。
・クラウドプロバイダは異なったアイデンティティプロバイダから標準フェデレーションフォーマットを受け入れる為の柔軟性を持つべきである。しかしながら現状の大多数のクラウドプロバイダは単一の標準（例えばSAML1.1やSAML2.0）だけをサポートしている。クラウドプロバイダには各種フェデレーションゲートウェイによって実装されることが考えられる複数のフェデレーショントークンをサポートすることが望まれる。
・組織は連携されたパブリックSSOと連携されたプライベートSSOの比較検討をすることを望むと考えられる。連携されたパブリックSSOはクラウドプロバイダとSAMLやWS-Federationの様な標準に基づき連携するが、一方で連携されたプライベートSSOはVPNを介して既存のSSOアーキテクチャを利用する。
・組織はトークンの発行と確認を管理するためにフェデレーションの実装を外部に出すためにフェデレーションゲートウェイを選択することを望むと考えられる。この方法を利用することで企業はフェデレーションゲートウェイに対して各種トークンの発行を委任することができる。そして、フェデレーションゲートウェイはトークンのフォーマットを変換することが可能である。

◆アクセスコントロールに関する推奨
クラウドサービスに関するアクセスコントロールソリューションの選択や妥当性のレビューは様々な側面を持ち、以下の考慮を伴なう。
・サービスやデータの種類に応じたアクセスコントロールモデルの適切さのレビュー
・ポリシーやユーザプロファイル情報の信頼できるソースを認識する
・データに対する必要なプライバシーポリシーへのアクセスサポート
・ポリシーとユーザ情報を特定する為のフォーマットの選択
・ポリシー管理ポイント（PAP）からポリシー決定ポイント（PDP）への伝搬ポリシーのためのメカニズムの決定
・
ポリシー情報ポイント（PIP）からポリシー決定ポイント（PDP）へのユーザ情報の伝搬に関するメカニズムの決定
・ポリシー決定ポイントからのポリシー決定の要求
・ポリシー強制ポイント（PEP）におけるポリシー決定の強制
・監査に必要なログ情報

◆IDaaSに関する推奨
Identity as a Service（IDaaS）はプライバシー、完全性、監査可能性についての追加の考慮をした上で、内部IAMの導入がそうしたようにベストプラクティスに従う必要がある。
・企業内ユーザにとって。管理者はクラウドプロバイダが提供するクラウドに安全にアクセスするために提供されるオプション、もしくは直接のVPN接続やSAML等の業界標準と強固な認証によるアクセスを比較レビューする必要がある。クラウドを使う事によるコスト削減は従業員情報が外部に保管されることに起因するプライバシー考慮に関するリスク緩和とバランスされる必要がある。
・パートナーなどの外部ユーザにとって。情報オーナーは彼らのSDLC※に脅威に対するアセスメントと同様にIAMの相互作用について盛り込む必要がある。アプリケーションセキュリティ（様々なコンポーネントの相互に作用、それらにより発生するSQLインジェクションやクロスサイトスクリプティングなど脆弱性）も同様に考慮され守られなければならない。
・PaaSカスタマーはどのIDaaSベンダがプロビジョニング、認証、アクセスコントロールポリシーに関する通信、情報監査について業界標準をサポートしているかの範囲を調査すべきである。
・プロプライエタリなソリューションはプロプライエタリなコンポーネントに対する透過性の欠如によりクラウドにおけるIAM環境に関して重大なリスクとなる。プロプライエタリなネットワークプロトコルや暗号化アルゴリズム、データ通信はしばしばセキュリティ低下や強固さの低下、相互運用性の低下をもたらす。外部化を行う上でIAMコンポーネントにオープンスタンダードを使うことは非常に重要なことである。
・IaaSカスタマーにとって。仮想サーバを起動する際に使用するサードパーティイメージはユーザとイメージ自身の信憑性について確認される必要がある。そのイメージに対して提供されるライフサイクル管理のサポートに関するレビューは社内ネットワークにインストールされるソフトウェアに対するのと同様の確認が必要である。

※SDLC：Software Development Life Cycle

FIM2010RC1 update2リリース

早くもupdate2がリリースされています。

今回からはMicrosoft Updateでのリリースになっており、現在カタログサイトからダウンロード可能です。








今回のリリースでは以下の領域に関する複数の更新を含んでいるとのことです。
•Sets
•Setup
•Codeless Provisioning
•Management Policy Rules
•Portal user interface
•Schema
•Self-service Password Reset
•Synchronization engine
•Workflow

また、update1までの不具合となっていたナビゲーションバーに出てくるリソースの数の不整合が今回のリリースで改修されたようです。
http://social.technet.microsoft.com/Forums/en/ilm2/thread/184bb2b7-b20a-4c8a-ab7d-d7098bd997ba

FIM2010のパフォーマンス その２

前回に引き続きパフォーマンスに関するネタです。
※前回同様に情報ソースはDarryl Russiさんのblogです。

今回は実際にパフォーマンステストを行った2種類のトポロジの紹介です。また、同時にどのようなハードウェアを使ったのかも紹介されています。
・トポロジ関連情報
http://blogs.msdn.com/darrylru/archive/2009/10/06/fim-2010-performance-testing-topology.aspx
・ハードウェア関連情報
http://blogs.msdn.com/darrylru/archive/2009/10/09/fim-2010-performance-testing-hardware.aspx

※製品チームがリリースに際して実際にテストを行っている環境（トポロジ、スペック）だそうです。マイクロソフトのIT部門のワークロードに対応するサイジングになっているということです。（あくまでテスト環境用のハードウェアですよ、、と断りはついていますが・・・つまりは冗長性についてはあんまり考慮してないってことです）

まず、テストに使ったハードウェアスペックですが、下記の2種類です。

コンポーネント	標準機	ハイスペック機
CPU	Core2 Quad Q6600 2.4GHz	Xeon E5410(Quad Core) 2.33GHz x 2
メモリ	4GB	32GB
ディスク	シングルドライブ	136GB(10krpm) x 8 【内訳】 Cドライブ（OS/アプリケーション） x 1 Eドライブ（SQLログファイル） x 1 Fドライブ（SQLデータファイル） x 6（RAID0）

次にトポロジです。

■標準的なトポロジ
いわゆるシンプルな構成です。
・ポータル、FIM Service、FIM Service用DBの同居（ハイスペック機)
・FIM Synchronization Service＋DB（ハイスペック機)
の2台構成









■NLBトポロジ
少々複雑な構成です。
・ポータル x2 (NLB)（標準機）
・FIM Service x 2 (NLB)（標準機）
・FIM Service用DB x 1（ハイスペック機)
・FIM Synchronization Service＋DB x 1（ハイスペック機)
の6台構成



















現実にはハードウェアロードバランサーを使うケースや各DBをクラスタリングするケース、既存のMOSSの中にフロント（ポータル）を取り込む構成など色々あるとは思いますが、あくまでテストのスコープがFIM単体のパフォーマンスなのでこのような構成でテストをしているようです。

次回以降、これらの環境を使って各コンポーネントの実際のパフォーマンス測定を行った結果をご紹介します。