2011年12月27日火曜日

[告知]カンターラ・イニシアティブ・セミナー2012 Winter

2/1にカンターラ・イニシアティブのセミナーをやります。

今回は、JNSA(日本ネットワークセキュリティ協会)のIDMワーキンググループとの共同開催ということで、両方にちょっとずつ絡んでいる私もパネルディスカッションに参加します。
テーマが「グローバル企業におけるID管理」ということで、純日本製SIerの私としては何を話そうか迷うところですが、、、

他にもJNSAのクラウド環境におけるアイデンティティ管理ガイドブックよりアイデンティティ管理プロジェクトにおける失敗事例のパターンの話や、特権管理ソリューションの話、マイナンバーの話など非常に幅広いテーマで講演があるので、月初という忙しい時期だとは思いますがよろしければ是非。

■告知ページ
http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=57606150

■アジェンダ

13:30    受付開始
14:00    開会挨拶  カンターラ・イニシアティブ ジャパン・ワークグループ
14:05-14:35 講演  「アンチパターンから学ぶID管理」
           JNSA ID管理WGより NTTコムウェア 駒沢 健
14:40-15:20 講演  「特権ユーザ管理とは ~登場の背景と求められる機能」
           日本CA株式会社 楠木 秀明
15:30-16:00 講演  「共通番号制度・国民ID解説」
           株式会社NTTデータ 技術開発本部 小山 武士
16:00-16:50 パネルディスカッション 「グローバル企業におけるID管理」
        パネラー
         JNSA ID管理WGリーダー 宮川 晃一(日本ビジネスシステムズ株式会社)
         日本オラクル株式会社 下道 高志
         伊藤忠テクノソリューションズ株式会社 富士榮 尚寛(MS MVP)
17:00頃 終了予定


2011年12月19日月曜日

[FIM2010] R2 で強化されたパスワード管理機能 - その1


# 久しぶりに本業?の FIM の話題です。

ようやく RC 版がリリースされた FIM2010R2 ですが、今回は新しく追加されたパスワード管理機能について試してみます。

無印のころは Windows ログオン画面でのパスワードリマインダ機能だけでしたが、R2 からは Web ベースでのパスワード登録およびパスワードリセット機能が実装されています。

・無印のころのパスワードリセット画面


































この機能は Windows クライアントのみ、且つ全員がドメインに参加しているという状況下においては非常に有用な機能でしたが、非ドメインユーザなどには使えない、という欠点がありました。
(ドメインユーザであれば PC にログオンできない環境下でも使える、というのは運用上とても良い機能でした)


その点、R2 からは Web ベースでのパスワードリマインダが実装されているので、以下の様な流れで秘密の質問の登録およびリセットを行うことが出来ます。(設定方法はそれなりに手間がかかるので、別途まとめます)
ちなみに今回は AD と FIM のユーザを同期した状態、且つ AD MA のパスワード変更を有効にした状態がベースです。ですので、FIM でパスワードをリセットすると Active Directory のパスワードがリセットされます。

・パスワード(秘密の質問)の登録画面



























































































# ちなみに相変わらず秘密の質問の回答に日本語は使えません。。


続いてパスワードリセット画面です。こちらも Web 化されています。





これで、無事にパスワードがリセットされました。
一旦ログオフして、再度ログオンするときは新しいパスワードになっているはずです。


2011年12月13日火曜日

Windows Azure Active Directory


Azure 方面では大幅アップデートでお祭り状態?になっているみたいですが、ひっそりとアイデンティティ関連に関してもアナウンスがされています。
詳細はこれから徐々に出てくると思われますが、現状出ている情報から見えるところだけとりあえず。


まず、タイトルが「Windows Azure Active Directory」になっています。
http://www.windowsazure.com/en-us/home/tour/access-control/

少しずつ本文から抜粋します。
Windows Azure Active Directory is a cloud service that provides identity and access capabilities for applications on Windows Azure and Microsoft Office 365. Windows Azure Active Directory is the multi-tenant cloud service on which Microsoft Office 365 relies on for its identity infrastructure. 


Windows Azure 上のアプリケーションおよび Office365 用のアイデンティティ&アクセス機能を提供、とあります。
これまで、似たようなサービスではありましたが、全く別の基盤として稼働してきた AppFabric ACS と Office365 のアイデンティティ・プラットフォームでしたが、ついに統合?されることになりそうです。(単なるブランド統合だけかもしれませんが)

【参考】
これまでの Office365 のアイデンティティ・プラットフォーム。
ACS と同様に AD FS2.0 とのフェデレーションが出来ましたがあくまで Offce365 専用。

































こんな記述もあります。
You can enable single sign-on, security enhanced applications, and simple interoperability with existing Active Directory deployments using Access Control Service (ACS), a feature of Windows Azure Active Directory

AppFabric ACS の位置づけが明確に Windows Azure Active Directory の一機能とされています。

こんな記載もあるので、やれることとしては既存の Active Directory と一緒に使うことによって SSO などを実現、とあるのでそれほど変わらないのかと。
You can quickly extend your existing on-premises Active Directory authentication to your cloud applications through ACS. By using your existing user directory as the authoritative identity provider, users are authenticated to your cloud applications with their existing accounts.   


標準技術への対応に関する記述は以下の通り。OpenID 2.0 との記載は以前からありましたが、OpenID Provider の追加は非サポートでした。今後はどうなるのかちょっと期待。
Integrated and customizable Home Realm Discovery so users can choose their identity provider with support for Windows Live ID, OpenID 2.0, Google, Yahoo, Facebook, and enterprise providers such as Windows Active Directory.


その他ですが、最近の Azure 界隈はかなり OSS に寄っている気がします。以下の記述を見ても Ruby の記述があるあたりが OSS 開発者を強く意識しているのかな?と思います。
ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby, and has out-of-the-box support for popular web identity providers including Windows Live ID, Google, Yahoo!, and Facebook. 


今回はまだリリースされている情報が少ないので、機能面ではあまり見えておらず、単なるリブランディングなのか?とも思えますが、引き続き要ウォッチです。

A Guide to Claim-Based Identity and Access Control 2.0 の eBook 版がリリース


以前のポストでも紹介したとおり、先日第2版もリリースされたお馴染み Claims Guide ですが、このたび eBook 版がリリースされています。
MSDN のサイトで公開されていたものです)

PDF でダウンロード出来るのでお手元のモバイル端末へ入れておくのが吉かと。
http://www.microsoft.com/download/en/confirmation.aspx?id=28362



2011年12月11日日曜日

[AD FS2.0]属性ストアへのアクセス権限について


前回に引き続き AD FS2.0 の属性ストアに関するネタです。

AD FS2.0 の属性ストアとして設定可能なのは、
・SQL Server
・LDAP
・カスタム
があることは前回紹介しましたが、各属性ストアへのアクセス権限については注意が必要です。

そもそも AD FS2.0 のサービスから各属性ストアへのアクセスはどのようなセキュリティ・コンテキスト(ユーザ)で実行されるのか?について理解しておくことが必要ですので、どんなユーザでアクセスが発生しているのかをカスタム属性ストアのコードの中にデバッグコードを書いて見てみました。
少々ベタですが、Initialize メソッドの先頭に以下の様に System.Environment.UserName (ユーザ名)、SystemEnvironment.UserDomainName (ドメイン名)をファイルへ出力するようにコードを書いてみます。

public void Initialize(Dictionary<string, string> config)
{
   System.IO.StreamWriter sw = new System.IO.StreamWriter(@"C:\temp\adfs.txt",false,System.Text.Encoding.GetEncoding("shift_jis"));
   sw.Write("ユーザ名 : " + System.Environment.UserName);
   sw.WriteLine();
   sw.Write("ドメイン名 : " + System.Environment.UserDomainName);
   sw.Close();

結果、ファイルには以下の様な文字列が書き込まれました。

ユーザ名 : IDP$
ドメイン名 : ADFS20
※コンピュータ名が IDP 、ドメイン名が ADFS20.LOCAL の環境下。

これは、AD FS2.0 のサービスを起動しているユーザ(シングル構成だとデフォルトで Network Service)を指しています。証拠にサービスの構成でサービス実行ユーザを Administrator に変更すると、以下の様に書き込まれる値が変わります。

ユーザ名 : Administrator
ドメイン名 : ADFS20


さて、これは
各属性ストアへ AD FS2.0 起動ユーザへのアクセス権限を与える必要がある
ということを意味します。(AD FS2.0 で認証されたユーザの権限ではないところがポイント)

MSDN の属性ストアに関連する記述を見るとデフォルトで設定できる、SQL Server および LDAP について以下の様な記述があります。(ポイントのみかいつまんでいます)
URL : http://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores(WS.10).aspx

■SQL Server
1. SQL Server 属性ストアを設定するときは「Server=CONTOSOSRV01;Database=UserAttributes;Integrated Security = True」という様な接続文字列を AD FS2.0 の属性ストアに設定する必要がある。

2. マイクロソフトとしては、SQL Server へのアクセスは Windows 統合認証を使うことを推奨する。もし SQL Server 認証を使う場合はユーザ名およびパスワードに関する情報が AD FS2.0 の構成データベースの中にクリアテキストで保持されることになる。


解説すると、接続文字列の中の「Integrated Security = True」の部分は SQL Server へのアクセスを Windows 統合認証で行うことを指しています。
もちろん、「Server=CONTOSOSRV01;Database=UserAttributes;User Id=MyUser; password= P@ssw0rd」という形で接続文字列を設定することも可能ですが、属性ストアのパラメータとしてそのまま AD FS2.0 に設定されてしまうので、パスワード部分が丸見えになってしまうので推奨しない、ということです。

ただ、Windows 統合認証を使う場合は上記で述べたように AD FS2.0 を実行しているユーザで SQL Server へアクセスしてしまうので、あらかじめ SQL Server 側で当該ユーザへのログオン許可および必要なロールの割り当てを行っておく必要があります。

■LDAP
1. LDAP 属性ストアを設定するときは RFC 2255 に記載されているような LDAP URL をパラメータに指定する必要がある。
(例:ldap://localhost:56000/cn=AdfsUsers,o=Microsoft,c=US)

2. LDAP 属性ストアへのアクセスは Windows 統合認証を使用する必要がある。


ポイントは SQL Server の場合と異なり、LDAP へのアクセスにはバインドユーザとパスワードを指定することが出来ないので、 Windows 統合認証をサポートする LDAP サーバ(実質 AD LDS くらいしかない?)を用意しておく必要がある、というところです。



上記を踏まえてカスタム属性ストアを作成する場合は以下の考慮が必要です。

・Windows 統合認証でアクセスできる場合は、属性ストア側に AD FS2.0 実行ユーザへの権限を与えておく必要がある
・独自の認証を使う場合は、AD FS2.0 側のパラメータとして設定を行うことは可能だがクリアテキストで保持されてしまうので注意が必要である


MSDN フォーラムなどを見ていると LDAP を使いたいけど Windows 統合認証が必須、というあたりに引っかかっている人が結構いそうなので、OpenLDAP 対応のカスタム属性ストアなどを作って公開したらヒーローになれるかも、、です。

2011年12月7日水曜日

[AD FS2.0]カスタム属性ストアを作成する


AD FS2.0はその名の通り初期状態では、参加している Active Directory ドメイン上の情報(属性)をクレームとして発行します。

例えば、

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"), query = ";userPrincipalName;{0}", param = c.Value);

といった形で要求記述言語を記載すれば Active Directory 上のユーザの userPrincipalName 属性を NameIdentifier タイプのクレームとして発行します。


他にも、AD FS2.0 の属性ストアとして利用できるのは標準で
・LDAP
・SQL Server
があります。

それらの標準で用意されている属性ストアにない情報をクレームとして発行したい、という場合はどうすればよいのか?というと、「カスタム属性ストア」を自分で作って(コーディングして)利用することが出来ます。


ここで少しおさらいですが、 SAML IdP の一般的な構造に従い、AD FS2.0 は以下の様な構造になっています。




























ここで注意なのですが、AD FS2.0 の属性ストアはあくまで属性オーソリティが参照する先のレポジトリである、という点です。つまり、AD FS2.0 の構成要素である認証オーソリティが参照する先はあくまで Active Directory である、という点です。
残念ながら認証オーソリティの参照先を別のシステム(LDAP や他のレポジトリ)に変更することは AD FS2.0 ではできません。(2要素認証などを含むカスタム認証を行う場合は、AD FS2.0 のログインページをカスタマイズすることである程度は対応可能です)

ですから、クレームに含まれる属性を SQL Server や LDAP や今回紹介するテキストファイルから取得することはできますが、これはそれらのシステムで認証を行うわけではなく、認証を行った後に属性を取得することが出来るだけである、ということになります。


前置きが長くなりましたが、早速実装してみます。

細かいところは MSDN の記載を参考にするとして、今回は基礎編として MSDN にサンプルとして記載されているカスタム属性ストアを組み込んでみます。
http://msdn.microsoft.com/en-us/library/ee895358.aspx

紹介されているサンプルはテキストファイルに記載されている属性情報をクレームとして発行する、というものです。


■レポジトリとなるテキストファイルの用意

まずは、元となるテキストファイルを作成します。(C:\temp\data.txtとして保存します)
EmployeeID,EmployeeName,Age,Department,Role
1,John,33,HR,Manager
2,Jane,25,Sales,Vendor
3,Tim,45,Marketing,Evangelist
4,Leann,33,IT,Administrator


■カスタム属性ストア用のライブラリの作成

次に、AD FS2.0 サーバ上に Visual Studio 2010 をインストールし、MSDN のページにあるサンプルコードをコピペして、DLL を作成します。プロジェクトの種類はクラスライブラリを選択します。
# ここで注意なのですが、.NET Framework は3.5を選択する必要があります。.NET Framework 4.0 で作成した DLL だと 3.5 でビルドされている AD FS2.0 から参照できません。 
# Microsoft.IdentityServer.ClaimsPolicy.dll という AD FS2.0 のライブラリを参照する関係で AD FS2.0 がインストールされている環境に Visual Studio をインストールします。(ライブラリをコピーすれば他の環境でもビルドできるとは思いますが、試していません)
# もちろん、WIF SDK もインストールしておく必要があります。

コードは先ほどの MSDN のページのサンプルをそのままコピー&ペーストしますが、その前に参照設定を行う必要があります。
必要なのは、
・Microsoft.IdentityModel
・Microsoft.IdentityServer.ClaimsPolicy
です。



























Microsoft.IdentityServer.ClaimsPolicy については AD FS のインストールフォルダ直下にあるので直接参照します。





























コンパイル出来たら作成した DLL ファイルを「 %Program Files%\Active Directory Federation Services 2.0 」以下にコピーしておきます。


■作成したライブラリを AD FS2.0 のカスタム属性ストアとして登録する

最後は AD FS2.0 に作成したカスタム属性ストアを認識させる作業になります。

まず、AD FS2.0 管理コンソールを起動し、[信頼関係]-[属性ストア]を選択して右クリックして出てくる[カスタム属性ストアの追加]メニューを起動します。





























表示名に「FileAttributeStore」、カスタム属性ストアのクラス名に「CustomAttributeStores.FileAttributeStore,CustomAttributeStores」を設定します。






































次にパラメータを設定します。
今回のサンプルでは
・パラメータ名:FileName
・値:c:\temp\data.txt
と設定します。






















ここまで出来るとカスタム属性ストアを使用する準備が整うので、あとは適当なアプリケーションから利用してみます。


■アプリケーションから利用する

通例に従い、証明書利用者信頼(Relying Party)を作成します。
要求規則ルールにカスタムルールを設定し、以下の様なルールを記載します。
例では、要求規則のルールに age が 45 の人の name と role 属性を取得し、クレームとして発行する、というルールとなっています。











































後は、実際にアプリケーションにアクセスしてみます。
今回のアプリケーションではわたってきたトークンからクレーム・タイプが role の値を取得して表示する、というロジックを記載しているので、以下の様に Evangelist という文字列が表示されます。























詳しくはサンプルで使ったソースを読むとわかるのですが、BeginExecuteQuery メソッドの中で渡されたパラメータに従い、ストアの中から任意の値を返す、というロジックを記載さえできればどんなレポジトリでも属性ストアとして登録することが可能です。

海外には PowerShell の実行結果をクレームとして発行するための PowerShell Attribute Store を作って公開している強者もいたりします。
以下、参考までに。
http://www.theidentityguy.com/articles/2011/11/19/powershell-attribute-store-for-ad-fs-20.html

2011年12月6日火曜日

[Office365] ディレクトリ同期ツールの64bit版はFIM2010のビルド5.x


先日のエントリで 64bit 版のディレクトリ同期ツールがリリースされたことを書きましたが、ようやくインストールする時間が取れたので少し構造を見てみました。

やり方としては非サポートですが、前回ベータ版で行った方法(Synchronization Server の管理コンソールを直接起動)です。

ベースとなっている物のバージョンですが、前回は Identity Lifecycle Manager 2007 FP1 がベースでしたが、64bit 化に伴い、 Forefront Identity Manager 2010 がベースになっています。

ビルドを見てみると、ビルド番号は 5.0.227.2 となっています。





































ん?5.x
これまで FIM2010(Synchronization Service)のビルドは 4.x (無印は 4.0.x、R2 は 4.1.x)でした。

参考)現状の FIM2010 のビルド一覧
4.0.2592.0 RTM
4.0.3531.2 http://support.microsoft.com/kb/978864
4.0.3547.2 http://support.microsoft.com/kb/2028634
4.0.3558.3 http://support.microsoft.com/kb/2272389
4.0.3561.2 http://support.microsoft.com/kb/2443871
4.0.3573.2 http://support.microsoft.com/kb/2417774
4.0.3576.2 http://support.microsoft.com/kb/2502631
4.0.3594.2 http://support.microsoft.com/kb/2520954
4.1.1906.0 R2 RC


ちなみにこれは歴史を振り返ると
・Zoomit VIA (マイクロソフトによる買収前) / 流石にビルドバージョンは知らない。。。
・Microsoft Metadirectory Server 2.x (日本未発売) / Build 2.x
・Microsoft Identity Integration Server 2003 / Build 3.x
・Identity Lifecycle Manager 2007 / Build 3.x
・Forefront Identity Manager 2010 / Build 4.x
という形で内部バージョンを持っていました。

ここで 5.x が本流の FIM とは別の流れで出てしまった、という事実は次の FIM のメジャーバージョンアップに何か影響があるのでしょうか。。。
まぁ同期のアーキテクチャは既に10年以上もほぼ変わっていないので、そろそろ別のものに??もしくは打ち止め??などと想像してしまいます。