IdM実験室: 1月 2010

2010年1月28日木曜日

どうなる？Sun IdM　( 2010/1/30 追記 )

2010/1/30更新

SunのシニアソフトウェアアーキテクトのSébastien Stormacq氏のblogにまとまっているので少々修正です。（@tkudoさんに感謝）

そろそろ眠気がピークですが、なんとかIdM部分だけは、、と思って頑張ってます。

というわけで、日本時間1/28 2:00-7:00という極東に住んでいることを後悔するようなスケジュールで開催されている「Oracle + Sun Strategy Update」ですが、IdM部分について軽く紹介しておきます。
（眠いので間違っている可能性ありです。気づいたら直します）

結果から書きますが、基本的な方針としては「Oracle製品に統合」です。

細かく分野ごとに見ていくとこんな感じです。

分野	方針	旧Sun製品	Oracle製品
Directory Services	Oracle Internet DirectoryとSun Directory Serverの両方をサポートする。OpenDSへの投資は継続する。	Sun Java System Directory Server	Oracle Internet Directory
Role Management	Sun Role ManagerはSuiteから切り出されてIdentity Analyticsへ	Sun Role Manager	Oracle Role Manager
Provisioning/Lifecycle Management	Oracle Identity Managerを戦略製品として継続させる。Sun Identity ManagerはSPMLアダプタとしてOracle Identity Managerへ統合される。Sun Identity ManagerはOracle Wavesetへリネーム。Sun Identity Managerからのマイグレーションツールを提供する予定。	Sun Identity Manager	Oracle Identity Manager
Access Management	Oracle Access Managerを戦略製品として継続させる。OpenSSOからのマイグレーションツールを提供する予定。OpenSSO STS機能を取り込みエンハンス。	OpenSSO	Oralce Access Manager
Virtual Directory	Oracle Virtual Directoryを戦略製品として継続させる	Sun Java System Directory Server EE	Oracle Virtual Directory
eSSO	Oracle Enterprise Single Sign-On Plusを戦略製品として継続させる	-	Oralce Enterprise Single Sign--On Plus
権限管理（Entitlement Management）	Oracle Entitlements Serverを戦略製品として継続させる	-	Oracle Entitlements Server
Identity Federation	Oracle Identity Federationを戦略製品として継続させ、OpenSSOのfedletを取り込む。OpenSSOからのマイグレーションツールを提供する予定。	OpenSSO	Oracle Identity Federation

※ちなみにSun Java System Directory Server Enterprise Editionに入っていたIdentity Synchronization for Windowsはどうなるんだろう？？LDAP-ADのお手軽同期ツールとしては良かったんですけどねぇ。

尚、サポートに関しては統合後も継続されるようですので、既存ユーザは保護されるようです。

とりあえずまた追加情報などあればアップデートしていきます。

2月は情報セキュリティ月間！

今からOracleとSunの今後の戦略に関する発表があるので、眠気覚ましにblogでも更新。

今日（というか昨日）はJNSAの賀詞交歓会＆JNSA賞の授賞式だったのでベルサーレ神田へ行ってきました。

賀詞交歓会は新年会というかお祭りなので、色々な方々が来ておられましたが、中でもガバメント系（総務省、経済産業省、内閣官房情報セキュリティセンター／NISC）の方々の冒頭挨拶で、みなさん口をそろえてパワーシフトの話と事業仕訳けの話をしておられたのが非常に印象的でした。まぁ当然と言えば当然なんでしょうが。。

NISCの方のご挨拶の中で「そう言えばそんなのあったな～」と思いだしたのが、2月2日は「情報セキュリティの日」という話。何で思いだしたかというと、どうやら今年の2月は「情報セキュリティ月間」になったという話があったため。かなり急な話だったらしく、まだNISCのページにも何にもアナウンスされてません。。。

他にもISF（Internet Security Forum）とJNSAの提携について改めて話があり、CEOのハワード・シュミット氏のビデオメッセージおよびCOOの（ビル・コーシー氏による挨拶がありました。

その後、賀詞交歓会の中の一コマであるJNSA賞の授賞式があったのですが、私の参加している「セキュリティにおけるアイデンティティ管理WG」がワーキンググループの部で受賞しました。
私も盾をいただいたのでその写真を。。

後ろにFenderのストラップが微かに見えるのはご愛敬。ちなみにストラップはFenderですがギターは何故かTuneのエレガットです。Tuneというとベースのメーカというイメージですが、ギターもちゃんと出してます。（すみません、全然関係ない話でした）

ちなみに賀詞交歓会の前に開催されていたNSF／Network Security Forum 2009では、IIJテクノロジーの方、ラックの方、Googleの方によるクラウドのセキュリティに関するパネルディスカッションなどがあったようです。残念ながら私は参加できなかったので資料だけ貰ってきましたが、全体にモヤっとした概念をモヤっとまとめるしかないのが現状のこの領域の話、ということのようでした。

と、四方山話をしているうちにそろそろLarry Ellisonの話の時間が迫ってきたので、このあたりで。。

2010年1月16日土曜日

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

意外とご好評を頂いた？このシリーズも今回で最終回です。

いよいよ今回は、
３．Azure上のアプリケーションを作成・発行する
４．シングルサインオンしてみる
をお送りします。

初回にも書きましたが、Azure上でもオンプレミスと同じコードが動きますが、環境面での違いを吸収するために少々設定が必要になります。

環境面での違いをまとめると、下記のようになります。

ポイント	Azure	オンプレミス
証明書のインストール方法	サービス毎に証明書をアップロード	IISへの設定
Webサイトへの証明書のバインド方法	プロジェクト側（WebRole）で使う証明書を指定	IISのサイトの設定
WIFコンポーネントの呼び出し方法	プロジェクトにWIFコンポーネントをパッケージングして一緒にデプロイ	アプリケーションサーバにインストールされているWIFコンポーネントへアクセス

では作業を始めます。
流れとしては、
・Azure上へサービスを作成する
・証明書を準備する
・Azure上へ証明書をアップロードする
・アプリケーションを作成する
・Azure上へデプロイ／実行する
・ADFS2.0にRelyingPartyを設定する
・Azure上のアプリケーションの動作を確認する
・オンプレミスアプリケーションとのSSO動作を確認する
となります。

少々ステップが多くなりますが、順番に見ていきます。

◆Azure上へサービスを作成する

　プロジェクトを開き、New ServiceからHostedサービスを作成します。
　注）ここで作成したサービス名を証明書にも使うので記録しておきます。
　　　今回は「pasvfed」という名前を使いました。

　サービスを追加し、Hosted Servicesを選択します。

　以下のパラメータでサービスを作成します。

項目	設定値	備考
Service Label	pasvfed
Public Service Name	http://pasvfed.cloudapp.net
Region	Anywhere US	何故かAnywhere AsiaだとDr. Watsonが出たので

◆証明書を準備する

　証明書を作成するのにネイティブ暗号化APIモジュール（CAPICOM）を使用します。
　もちろん上記リンクからダウンロードしても良いのですが、Identity Training Kitに入っているので今回はそちらを使いました。（CAPICOMそのものよりも後で出てくる証明書作成のバッチファイルが欲しかったので）
　※ちなみにCAPICOMは＜Identity Training Kitインストールフォルダ＞\Labs\WindowsAzureAndPassiveFederation\Source\Setup\Scripts以下にあるcapicom_dc_sdk.msiです。

　インストールが終わったら証明書の作成とインストールを行います。
　インストールは同じく＜Identity Training Kitインストールフォルダ＞\Labs\WindowsAzureAndPassiveFederation\Source\Assets以下にある、CreateCert.cmdを使います。

　まず、Visual Studioコマンドプロンプトを管理者で実行します。

　CreateCert.cmdのあるフォルダへ移動して、以下を実行します。

xxxx:\> CreateCert.cmd pasvfed

　このとき、引数に先程Azure上で作成したサービスの名称を渡します。

　実行すると、秘密キーのパスワードの作成、秘密キーのパスワード入力を求められるので「abc!123」を入力します。
　※CreateCert.cmdをそのまま使う場合、パスワードはabc!123である必要があります。
　　詳しくはバッチファイルの中を見るとわかります。

　その後、証明書インストール時にセキュリティの警告が出るのが「はい」をクリックします。

　コマンドが成功するとcertsフォルダの中に、
　・pasvfed.cloudapp.net.cer
　・pasvfed.cloudapp.net.pfx
　・pasvfed.cloudapp.net.pvk
　という3つのファイルが出来上がります。

◆Azure上へ証明書をアップロードする

　先程作成した証明書をAzure上へ予めアップロードしておきます。手順としてAzureのサービスのCertificatesからManageをクリックします。

　作成した証明書（pfxファイル）を選択肢、パスワードに先ほど指定した「abc!123」を指定し、uploadを行います。

　成功するとInstalled Certificatesにアップロードした証明書が表示されます。

◆アプリケーションを作成する

・プロジェクトの作成

　オンプレミス側で実行したのと同様にVSを管理者として起動し、新しいプロジェクトを以下の通り作成します。

項目	値	備考
プロジェクト名	pasvfed	Azure上のサービス名と合わせます
プロジェクトの種類	Visual C# → Cloud Service	もちろん言語は任意
テンプレート	Windows Azure Cloud Service
追加するロール	ASP.NET Web Role
ロール名	Web	もちろん任意

・SSLの設定

　次に、WebロールのSSL設定を行います。
　ソリューションエクスプローラからpasvfed→Roles→Webを右クリックしてプロパティウィンドウを表示します。

　Certificatesメニューを開き、「Add Certificate」をクリックし、以下の通り証明書を設定します。

項目	値	備考
Name	pasvfed
Store Location	Local Machine	デフォルト
Store Name	My	デフォルト
Thumbprint	右側のボタンをクリックして先ほど作成したpasvfedという名前の証明書を選択する

　次に追加した証明書を使うようにエンドポイントの設定を行います。Endpointsメニューを開き、以下の様に設定します。

項目		値	備考
HTTP		無効
HTTPS		有効
	Name	HttpsIn	デフォルト
	Port	443	デフォルト
	SSL certificate name	pasvfed	ドロップダウンリストから選択

・参照設定の追加

　Webロールのプロジェクトの参照設定にオンプレミスと同様にMicrosoft.IdentityModelを追加します。
　1点異なるのが、Microsoft.IdentityModelのプロパティに以下のパラメータを設定する必要がある点です。

　・ローカルコピー：True
　・特定バージョン：False

　これは、Azure上のアプリケーションからWIFコンポーネントへアクセスできないため、
、ローカルコピーを有効にして強制的にプロジェクトパッケージにコンポーネントを含めるために行う設定です。

・STSへの参照を設定

　これはオンプレミスと全く同じ手順です。
　Webロールを右クリックして出てくるAdd STS referenceからWizardを開き、以下の設定を行います。※オンプレミスと異なる点はApplication URIのみです。

ステップ	設定項目	設定値	備考
Welcome	Application configuration location	プロジェクトのweb.configファイル	初期状態で指定されているので変更不要
Welcome	Application URI	https://pasvfed.cloudapp.net	発行先となるURIを指定
Security Token Service	Security Token Service (STS) option	Use an existing STS	既に作成したADFS2.0をSTSとして指定
Security Token Service	STS WS-Federation metadata document location	https://adfs20.eidentity.local/FederationMetadata/2007-06/FederationMetadata.xml	ADFS2.0のMetadataのエンドポイントを指定
STS signing certificate chain validation error	Certificate validation option	Disable certificate chain validation	STSが自己署名入り証明書を使っているため、証明書チェーンの確認を無効化する
Security Token encryption	Security Token encryption option	No encryption

・Web.configの編集

　Add STS referenceでWeb.configは書き換わるのですが、Azure上にアップロードした証明書の参照に関する設定を一部手動で追加する必要があります。
　場所は、タグの内で、以下を追加します。

※ThumbprintはWebロールに設定した証明書のものを使用

・Default.aspxのコーディング

　いよいよ実装ですが、コードはオンプレミスと全く同じものを使います。

　ここまででアプリケーションの実装は完了です。次はいよいよAzure上へのデプロイです。

◆Azure上へデプロイ／実行する

　ソリューションエクスプローラからpasvfedプロジェクトを右クリックして「発行」をクリックします。

　自動的にパッケージファイルが作成されたフォルダとブラウザが開き、Azureのサイトへ移動されます。

　プロジェクトからサービスを開き、Production環境のDeployボタンをクリックします。
　※今回は直接Production環境へデプロイします。これは、Azure上のアプリケーションはローカル、ステージング、プロダクションのそれぞれの環境でURIが変わるため、Passive Federationではアプリケーション→STS→アプリケーションとリダイレクションで遷移させる際に実行環境によって遷移先が変わってしまうためです。本当はHOSTヘッダをみて遷移先を変えるなどの工夫をするのですが、STSにADFS2.0を使う場合はそのあたりの作り込みが出来ない？ので、私は開発環境、ステージング環境もそれぞれRelying Partyとして登録しています。（ただの調査不足かも知れませんが）

　先ほど出来上がったパッケージファイルと構成ファイルをアップロードします。
　ラベルは適当な文字列でOKです。

　デプロイが完了したらRunをクリックしアプリケーションを実行します。

　ステータスがInitializingになると、しばらく時間がかかるのでその間にSTSの設定をしておきましょう。

◆ADFS2.0にRelyingPartyを設定する

　これは前回オンプレミスで作成したのと同様の手順です。今回作成したアプリケーションのFederationMetadata.xmlを読み込ませると自動的にRelyingPartyのURIとしてpasvfed.cloudapp.netが設定されます。

◆Azure上のアプリケーションの動作を確認する

　そんなことをしているうちに、AzureのサービスのステータスがReadyになります

　準備が出来たら、ブラウザでhttps://pasvfed.cloudapp.net/へアクセスしてみます。
　オンプレミスと同じようにSTSへリダイレクトされ、ログインするとAzure上のアプリケーションが表示されます。

◆オンプレミスアプリケーションとのSSO動作を確認する

　最後に、本当にオンプレミスとシングルサインオンになっているかを試してみます。

　最初にオンプレミスへアクセスします。
　するとSTSへリダイレクトされ、オンプレミスアプリケーションが表示されます。

　そのまま、オンプレミス上の「Azureアプリケーション」というハイパーリンクをクリックします。すると今度はSTSへのログオンすることなく、Azure上のアプリケーションが表示されます。

　ということで、今回作成した環境で本当に基礎的なクレームベースのWebアプリケーションではありますが、オンプレミスとクラウドのアプリケーションのシングルサインオンが実現出来ました。

　他にも色々とやりたい事が尽きないのですが、是非今度はOpenSSOとADFS2.0のフェデレーション環境下でオンプレミスはOpenSSO、AzureはWIF/ADFSという環境でのシングルサインオンとかにも手を出したいところです。

2010年1月14日木曜日

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

前回のポストがtwitterで意外と反響がありましたので、取り急ぎ続きを、、ということで今回は「２．オンプレミスのアプリケーションを作成・発行する」をお送りします。

実際の流れは下記の通りです。（今回はWindows7上のIIS7.5をアプリケーションサーバとして利用しています）

１．WIFを使ったClaimベースのWebアプリケーションを作成する
２．STSへのRelying Partyの設定
３．動作確認

では、それぞれのステップについて手順を見ていきます。

１．WIFを使ったClaimベースのWebアプリケーションを作成する
　ADFS2.0を使ったPassiveFederationを行う場合、アプリケーション（Relying Party）はSSLが有効化されている必要があるため、手順書は省略しますがあらかじめローカルのIISでSSLが使える状態にしてく必要があります。（今回、アプリケーションのデプロイ先をDefault Web Siteにしましたので、あらかじめ作成した自己署名入り証明書をhttpsバインドに設定しました）

　では、早速アプリケーションの実装を行います。必要となるのは以下のステップです。
　・参照設定の追加
　・STS参照の追加
　・アプリケーションの実装
　・アプリケーションの発行

　まずはVisual Studioを管理者として実行します。（STS参照の追加をするためには管理者権限が必要です）

　次に新しいプロジェクトを以下の通り作成します。

項目	値	備考
プロジェクト名	onpremise_pasvfed	もちろん任意
プロジェクトの種類	Visual C# → Web	もちろん言語は任意
テンプレート	ASP.NET Webアプリケーション

　プロジェクトが起動してきたらソリューションエクスプローラよりWIFへの参照を追加します。追加するコンポーネントはMicrosoft.IdentityModelです。

　次にSTSへの参照を追加します。
　同じくソリューションエクスプローラからソリューションを右クリックして出てくる「Add STS reference」メニューをクリックします。
　※Add STS referenceが出てこない場合は管理者としてVisual Studioを実行してみてください。

　Federation Utilityが起動してきますので、以下の通り値を設定します。
　STS側でも自己署名入りの証明書を使っているので途中証明書チェーンの確認で警告が出ますが続行してください。

ステップ	設定項目	設定値	備考
Welcome	Application configuration location	プロジェクトのweb.configファイル	初期状態で指定されているので変更不要
Welcome	Application URI	https://windows7.eidentity.local/onpremise_pasvfed/	発行先となるURIを指定
Security Token Service	Security Token Service (STS) option	Use an existing STS	既に作成したADFS2.0をSTSとして指定
Security Token Service	STS WS-Federation metadata document location	https://adfs20.eidentity.local/FederationMetadata/2007-06/FederationMetadata.xml	ADFS2.0のMetadataのエンドポイントを指定
STS signing certificate chain validation error	Certificate validation option	Disable certificate chain validation	STSが自己署名入り証明書を使っているため、証明書チェーンの確認を無効化する
Security Token encryption	Security Token encryption option	No encryption

　ユーティリティが終了するとソリューションエクスプローラにFederationMetadata.xmlが追加されているのと、Web.configの内容がSTSを参照する形に変更されます。

　次はいよいよアプリケーションの実装を行います。
　今回はSTSによって発行されるセキュリティトークンからname属性のClaimを取り出して画面上のラベルに表示する、というアプリケーションを実装します。

　実装するコードは下記の通りです。Page_load時にトークンからClaimを取り出してClaimTypeがnameならば値を画面上のラベルに表示します。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.IdentityModel.Claims;
using System.Threading;

namespace onpremise_pasvfed
{
　　public partial class _Default : System.Web.UI.Page
　　{
　　　　protected void Page_Load(object sender, EventArgs e)
　　　 {
　　　　　　IClaimsIdentity caller = (IClaimsIdentity)Thread.CurrentPrincipal.Identity;

　　　　　　foreach (Microsoft.IdentityModel.Claims.Claim c in caller.Claims)
　　　　　　 {
　　　　　　　　if (c.ClaimType == Microsoft.IdentityModel.Claims.ClaimTypes.Name)
　　　　　　　　{
　　　　　　　　　　lbl_claim_name.Text = c.Value;
　　　　　　　　　　 break;
　　　　　　　　}
　　　　　　}

　　　　}
　　}
}

　ここまでくると後はアプリケーションの発行だけです。今回はローカルIIS上にアプリケーションを発行しました。
　ここまででアプリケーションの実装・発行は完了です。

２．STSへのRelying Partyの設定
　　・FederationMetadata.xmlの読み込み
　　・Claimのマッピングルールの設定

　今度はSTS側への設定です。基本的にADFS2.0のSTSはレルム指定をしたホワイトリスト型なので、あらかじめ上記で作成したアプリケーションを指定してRelying Partyを定義しておく必要があります。

　ADFS2.0の管理コンソールを開くと、「Required: Add a trusted relying party」というタスクが表示されているので、クリックしてAdd Relying Party Trust Wizardを開始します。

　Wizardに設定する項目は下記の通りです。

ステップ	設定項目	設定値	備考
Select Data Source	Select an option that this wizard will use to obtain data about this relying party	Import data about the relying party from a file
Select Data Source	Federation metadata file location	アプリケーション側のFederationMetadata.xmlファイル	必要であれば予めADFSサーバへプロジェクトディレクトリ以下のFederationMetadata.xmlファイルをコピーしておく
Specify Display Name	Display Name	https://windows7.eidentity.local/onpremise_pasvfed/
Choose Issuance Authorization Rules	Relying party's issuance authorization rule	Permit all users to access this relying party

　Wizardが終わると、Claimマッピングのルールエディタが起動しますので、ルールを追加していきます。

　Add Ruleボタンをクリックすると、Add Transform Claim Rule Wizardが起動してきますので、下記の通り値を設定します。

ステップ	設定項目	設定値	備考
Choose Rule Type	Claim rule template	Send LDAP Attribute as Claims	Active Directoryの属性をクレームにマッピングします
Configure Claim Rule	Claim rule name	onpremise_pasvfed	任意です
	Attribute store	Active Directory
	LDAP Attribute	SAM-Account-Name	ペアでマッピングさせます
	Outgoing Claim Type	Name	ペアでマッピングさせます

　これで一応アプリケーションもSTSも準備が整いましたので、最後に動作確認を行います。

３．動作確認

　早速アプリケーションにアクセスしてみます。ブラウザから「https://windows7.eidentity.local/onpremise_pasvfed/」にアクセスします。

　STSであるadfs20.eidentity.localへリダイレクトされますので、ドメインユーザで認証を受けます。

　再度リダイレクトされ、アプリケーションが表示され、claim（name）が正しく取得できていることが分かります。

　今回はオンプレミス環境でWIF/ADFS2.0を使ったClaimベースのWebアプリケーションを実装しましたが、次回はいよいよAzure上で同様のアプリケーションを実行してみます。

MVP Award Giftが届きました！

先日の投稿でMVPアワードをいただいたことはご報告しましたが、本日MVP Award Giftなるものが届きました。

しかしデカいし重い！2.5Kgくらいあります。
記念に写真を載せておきます。

ちなみに、盾の左側の年が入った物が外れます。
MVP事務局からの連絡の中に「エコなギフトをお楽しみに」的なコメントがあったのは、これだったんですね。更新のときは年が入ったオブジェだけが送られてきて積み上げていく、という方式なんですね。

来年もオブジェを積み上げられるようにがんばります！

2010年1月12日火曜日

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アプリケーションを作成します。

2010年1月5日火曜日

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などを使って負荷試験をして実際に使用する各ハードウェアのスペックなどを決定していく、ということになります。