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年以上もほぼ変わっていないので、そろそろ別のものに??もしくは打ち止め??などと想像してしまいます。

2011年12月4日日曜日

Tao of Attributes - 属性之道 於京都 に参加してきました


11/30 の Internet Week および 12/1 の OpenID Summit Tokyo に引き続き 12/2 は京都にて「Tao of Attributes - 属性之道 於京都」が開催されました。

私は OpenID Summit Tokyo と Tao~ に参加したのですが、 OpenID Summit 側にはプレスも入っていましたし、他にもまとめてくれている人がいる(これとかこれ)ので、今回は Tao~ について少し書いておきたいと思います。

といっても当日参加された方はご存じだとは思いますが、かなりカオスな感じ(良い意味で)で進んだワークショップだったのではっきり言って理解&メモしきれていません。(全編英語でしたし)

まぁ一番の収穫?はこの分野で世界的にもトップを走っている方々でもまだまだ整理がしきれていないんだな、という妙な安心感?が得られたこと。。です。

アジェンダの順に徒然とメモを書いておきます。

Session 1 Tao of Attributes

1. Tao of Attributes / Ken Klingenstein, Internet2

 ・ロールとは何か?
  →属性、クレームをまとめたもの
  →誰がまとめるのか。コミュニティ、会社、属性プロバイダ・・・など
  →動的に変化するもの
  →それっていわゆる「アイデンティティ」だよね?

 ・メタデータの重要性
  →相互フェデレーションを可能とする

 ・メタデータの新しい要素
  →LoA(Level of Assuranse)※前日の OpenID Summit でも属性単位の LoA の話が出ていた
  →グラフィカルなアイコン
  →サービス属性、、など
  →ユーザの同意が必要

 ・属性オーソリティ(発行元)のタイプ
  ・企業:従業員コードとか
  ・政府機関、自治体:パスポート番号とか
  ・一時的なもの:位置情報とか
  ・コミュニティ
   ・フォーマル:バーチャルな組織
   ・インフォーマル:うわさ
  ・自分自身:使用する言語とか

 ・PII(Personal Identifiable Information)の分類(かっこないは例)
  ・個人を特定しない属性(ePSA)
  ・プライバシのために設計された間接的な識別子(ePTID)
  ・プライバシのために設計されていない間接的な識別子(IPアドレス)
  ・直接の識別子(名前、住所)
  ・メールアドレスとFAX番号
  ・位置情報(携帯電話)
  ・センシティブ情報(健康状態、人種、宗教)


2. Attribute Exchange within eduGain Members and Scheme / ValterNordh, eduGAIN

 ・eduGain のサービスの紹介
  ・http://www.geant.net/service/edugain/pages/home.aspx
  ・フェデレーション間の接続サービス(インターフェデレーションサービス)
  ・ディスカバリサービス
  ・メタデータサービス(MDS)

 ・メタデータのやり取りの方法
  ・フェデレーションからMDSへのメタデータの送付(アップストリーム)
  ・フェデレーションがMDSよりメタデータの取得(ダウンストリーム)

 ・属性リリース問題
  ・IdP管理者はどの属性が他のフェデレーションへ渡されているのかを知る必要がある
   (eduGainではメタデータの中のスキーマで工夫)


3. Attribute Verification Methods / Kick Willemse, OpenID Foundation

 メモれず・・・
 属性の分類と必要に応じて対象の属性が保証されていることが必要、という話。
 (さすがに資料なしのチョークトーク、且つカオスな感じにはついていけず)


4. Good Practice in Japan: Credit Mutual Exchange in Kyoto eLearning Consortium / Toyokazu Akiyama and Koji Ozaki, Kyoto Sangyo University

 ・eラーニングシステムをコンソーシアム参加大学の間で共有するために Shibboleth を導入した
  ・コンソーシアムには50の大学が参加
  ・生徒が自身で登録して利用するシステムだったため、各大学の事務局が各登録を確認していたが手間が大かった
  ・Shibboleth を導入して各大学の IdP と連携出来る様に。


5. Scope of SCOPE for OpenID Connect / Nat Sakimura, OpenID Foundation

 時間切れでスキップ



Session 2 Level of Assurance

6. GakuNin LoA Story / Hiroyuki Sato, University of Tokyo

 時間切れでスキップ


7. Challenge at Kyoto University / Yasuhiro Nagai, Kyoto University

 ・LoA は「利用頻度 x セキュリティレベル」の2軸で考えている
 ・各セキュリティレベルに応じて以下の認証レベルを導入している
  Level 1 ) フェース to フェース の認証なし
  Level 2 ) 静的パスワード+ICカード
  Level 3 ) 静的パスワード+ICカード+動的パスワード(ワンタイムパスワード)
  Level 4 ) 静的パスワード+ICカード+電子証明書
 ・電子証明書は学生証(Felica)に最初から入れてある


8. The University PKI Architecture in Japan and the LoA / Yasuo Okabe, Kyoto University

 ・3つのレイヤーで PKI を構築/利用
  ・Open Domain PKI / SMIMEなど外部とのやり取りに利用
  ・Campus PKI / キャンパス内システムに利用
  ・Grid PKI / コンピューターグリッドに利用

 ・UPKIの仕様は以下のURLより
  https://upki-portal.nii.ac.jp/upkispecific/specific


9. Discussion

 時間切れ、というより各セッション内で。。。


10. Dinner

 がんこ
 絶景でした。山縣有朋の別邸だったそうです。


2011年12月1日木曜日

OAuth 2.0 仕様書の翻訳版リリース!

AppFabric ACSv2 や WIF を使ったり、facebook をはじめとするソーシャル API を使おうとすると避けて通れないのが OAuth です。

これまでも OpenID Technight などで仕組みの解説がありましたし、一部当ブログでも紹介しましたが、厳密に知ろうと思うと原文のスペックを読むしかなく、ハードルが高かったのが現状です。

そんな方に朗報です!
OpenID Foundation Japan の翻訳ワーキンググループの活動で OAuth 2.0 core draft 22 および Bearer draft 11 の仕様書の日本語版がリリースされました。
(私も一部お手伝いをさせていただきました)

http://openid-foundation-japan.github.com/

ぜひ、一度ご覧いただければと思います。

2011年11月27日日曜日

MCTS: Forefront Identity Manager 2010, Configuringの提供開始

以前のポストでベータ版が提供され始めたことをお知らせしましたが、11/20から正式版が提供され始めています。

日本でもまだ英語ではありますがプロメトリックで受験できるようになりました。(070-158)
225分の長丁場ではありますが、通常のMCTS試験と同様に\15,000で受験できるので受けてみるのもありかと思います。(目指せ日本初?)

試験範囲を再掲しておきます。
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-158&locale=en-us


Plan a FIM Implementation and Install FIM (21 percent)
  • Plan and design FIM topology.
    • This objective may include but is not limited to: identify single point of failure; match topology to performance requirements; capacity planning; design highly available implementations for FIM Service and Portal
  • Install the FIM Service and the FIM Portal.
    • This objective may include but is not limited to: Microsoft SharePoint web configuration; service account permissions; prerequisites; certificates; groups
  • Upgrade Microsoft Identity Integration Server (MIIS)/Microsoft Identity Lifecycle Manager (ILM) to FIM 2010.
    • This objective may include but is not limited to: plan for upgrade; recompiling extensions; upgrading SQL databases; upgrading third-party clients
  • Deploy and manage client components.
    • This objective may include but is not limited to: automated installs; client images; multi-language support installation; plan for configuration of Microsoft Outlook for group management (Outlook plug-in for approvals and group management); use Group Policy objects (GPOs) to manage FIM client components; registry settings on client machines
  • Implement disaster recovery for FIM 2010.
    • This objective may include but is not limited to: backup and restore; FIM Service, FIM Portal; Sync Service; initial load scenarios; key backup and recovery
Plan and Configure Core Portal Functionality (19 percent)
  • Plan and configure user and group provisioning.
    • This objective may include but is not limited to: provisioning to Active Directory; deprovisioning; data-driven provisioning and deprovisioning; configure Management Policy Rules (MPR)/workflow/sync rule triples required for provisioning in the portal; expected rule entries; detected rule entries; workflow parameters
  • Plan and configure group management.
    • This objective may include but is not limited to: configure dynamic groups (query-based) in the portal; owner-based groups and approvals; distribution groups; security groups
  • Plan and configure synchronization rules. 
    • This objective may include but is not limited to: inbound and outbound sync rules; create objects in metaverse using declarative rules; advanced attribute flows; relationships
  • Plan and configure authorization and action workflows.
    • This objective may include but is not limited to: configure approvals including multiple approvals and escalations; notifications; deploying and configuring custom workflow activities
  • Plan and configure security permissions and Management Policy Rules (MPRs).
    • This objective may include but is not limited to: delegated administration; plan and implement user profile self-service; plan and implement group self-service; temporal objects; sets and set membership
Configure Advanced Portal-Based Scenarios (17 percent)
  • Configure the Resource Control Display Configuration (RCDC) for object and attribute display.
    • This objective may include but is not limited to: RCDC capabilities; validations; attribute permissions; data sources and data binding; form controls
  • Customize the user experience.
    • This objective may include but is not limited to: search scopes; menu navigation items; organizational branding; home page configuration; create and configure email templates; usage keywords
  • Extend the portal schema.
    • This objective may include but is not limited to: resource types; attributes; bindings; schema validation; synchronization filters
  • Plan and configure self-service password reset and registration.
    • This objective may include but is not limited to: authentication workflow for password reset and registration; QA gates; case sensitivity; lockout gates; password reset action workflow
  • Write and interpret XPath queries.
    • This objective may include but is not limited to: create valid FIM XPath filters; reference objects and attributes; filters; conditions
Confige FIM Synchronization (22 percent)
  • Create and configure standard management agents (MAs).
    • This objective may include but is not limited to: SQL Server MA; Certificate Management MA; Active Directory MA; file-based MAs; difference between call-based and file-based MAs; attribute flows; filters; projection rules; join rules; deprovisioning rules
  • Create and configure the FIM Service MA.
    • This objective may include but is not limited to: resource type mapping; Synchronization Rule filter; understand the constraints of the FIM MA; attribute flow
  • Configure the metaverse.
    • This objective may include but is not limited to: plan precedence; extend the schema; object deletion rules
  • Create and automate run profiles.
    • This objective may include but is not limited to: clearing run history; multi-step run profiles; run sequencing
  • Implement rules extensions.
  • Install and configure password synchronization and Password Change Notification Service (PCNS).
    • This objective may include but is not limited to: configure Active Directory MA; install services on domain controllers; schema changes related to PCNS; service principal names
Monitor and Maintain FIM (21 percent)
  • Migrate the FIM configuration between environments.
    • This objective may include but is not limited to: FIM portal configuration; DLLs and code; synchronization service server configuration; run scripts and automation tools; Windows PowerShell scripts; how to move configurations from development to test to production
  • Perform root cause analysis of provisioning issues.
    • This objective may include but is not limited to: issues with management policy rules, set definitions, workflows, and expected rule entries; misconfiguration of synchronization service server; coexistence of classic provisioning and declarative provisioning; result sequence
  • Perform root cause analysis of issues related to password management.
    • This objective may include but is not limited to: issues with password synchronization; self-service password reset; requirements for registration; end-to-end process
  • Perform root cause analysis of issues related to data flow and unexpected data.
    • This objective may include but is not limited to: data discovery issues; join issues; filter issues; run profile issues; threshold issues; Stack trace; precedence issues; object deletion rules
  • Perform root cause analysis of permissions issues.
    • This objective may include but is not limited to: MPR definitions; set definitions; portal permission errors; service account permissions; provisioning issues; synchronization service server roles

2011年11月26日土曜日

FIM2010R2 RCがリリース


先週のニュースですが、7月末のベータ版から4か月弱、ようやくRC版(Release Candidate)がリリースされました。

特にベータ版以降の新規の改善点はなさそうですが、先日より物議を呼んでいる(KB2520954)についても反映されてくるものと思われます。
※このKBについては別途エントリを書こうと思います。かなり影響が大きそうですので、ちょっと検証中。。。

<新機能・改善点>
・レポーティング
・Webベースでのセルフ・サービス・パスワード・リセット(SSPR)
・FIMデータベースのパフォーマンス改善
・FIM Add-In の Outlook 2010 サポート
・Sharepoint 2010 のサポート
・トラブルシューティングの改善

また、Microsoft Server and Cloud Platform Blog で Mark Wahl さんが書いている内容によると、
・SSPRの新しい認証ゲート
・追加レポート
・ECMA2
が拡張のポイントだそうです。

ダウンロードは以下より(登録が必要です)
https://connect.microsoft.com/site433/Downloads


他には同時に Lotus Domino 8 connector もリリースされています。これはまだFIM2010R2のRC版用ですが、このリリースより Domino 8.x の管理が出来る様になっています。
尚、10月末にリリースされた新しい拡張管理エージェント開発フレームワーク(ECMA2)をベースに開発されています。

2011年11月19日土曜日

Office365 ディレクトリ同期ツールの64bit版がリリース


長らく課題だった「Office365のディレクトリ同期ツールが32bit環境でしか動作しない」件にようやく決着がつきました。
参考)以前のポスト:ディレクトリ同期ツールを使って Office365 へのユーザ同期を行う

中身は9月のセミナで少し話したようにILM2007FPベースからFIM2010ベースになったようです。
ネタ元:http://msgeneral.blogspot.com/2011/11/64-bit-support-directory.html
     http://community.office365.com/en-us/w/sso/555.aspx


ダウンロードは管理ポータルからできます。












しかし、11/19現在日本語版のディレクトリ同期ツールのダウンロードが出来ません。サポートに通報しておいたのでそのうちダウンロード出来る様になるとは思いますが。。。
# 11/26 正常にダウンロード出来る様になったのを確認しました。




















尚、32bit版からのアップグレードですが、当然64bitOS上で動くので新規に64bitの環境を用意する必要がありますので、そのままアップグレードすることはできません。新規に64bit版をインストール・設定するときは32bit版の同期ツールをアンインストールする(もしくは止めておく)ことが必要です。
モジュールが入手できるようになったらもうちょっと詳しく試してみたいと思います。

これであとはFIM2010用の独立した管理エージェントとしてのリリースがされれば念願のマルチフォレスト対応なども実現すると思いますので、引き続き要ウォッチです。

2011年11月4日金曜日

AD FS2.0 トレーニングコース プレビュー会に行ってきました

ついに日本でも AD FS2.0 のトレーニングコースが11月末から始まります。
今日はコース内容のレビュー会に行ってきました。 

内容としては、AD FS2.0 というかアイデンティティ・フェデレーションとはどういうものなのか?から始まり、AD FS2.0 の実装方法、WIF を使った簡単なクレーム・ベースのアプリケーションの作成、 SharePoint 2010 および Office 365 との実際の連携、トラブルシューティングの方法の紹介を実際の環境を使ってハンズオン形式で体験する、というものです。 

主催:クリエ・イルミネート
コース名:ADFS 2.0 による ID フェデレーションの実装
http://www.crie-illuminate.jp/Pages/CourseList/CI511-H.aspx

講師は Directory Service の MVP として有名な国井さんです。

通常3日間のコースを MS 安納さんをはじめ、Directory Service の MVP や SharePoint 、 Office365 の MVP で1日で集中的に試す、という会だったので色々な意味で「濃い」会でした。

また、トレーニング教材が400ページにおよぶ大作!で国井さんが TEC や Oxford Computer Group のトレーニングなど、実際に足を運んで調査をしてきた集大成となっているので、この資料を見るだけでもかなり勉強になります。

プレビュー会で使った資料の目次は公開しても OK ということなので写真を載せておきます。
これから Office365 のオンプレミス連携を計画している方はぜひとも受講してみてはいかがでしょうか?


































































































































































2011年11月1日火曜日

Office365 の Cloud Control Matrix への対応

英語版では少し前(6月)にリリースされていた Office365 の Cloud Control Matrix ( CCM ) への対応に関するドキュメント「Request for Information (情報提供依頼書) に対する標準的なレスポンス - セキュリティおよびプライバシー」の日本語版が10月末にリリースされました。

- ダウンロード URL
 http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=6dd73e12-95d9-4834-98b4-49bd65a85cbe

で、CCM って何よ?という人のために簡単に解説しておくと、以前も紹介したことのある Cloud Security Alliance ( CSA ) という団体が出しているコントロール・フレームワークで、以下の様に説明されています。

The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains. The foundations of the Cloud Security Alliance Controls Matrix rest on its customized relationship to other industry-accepted security standards, regulations, and controls frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP and will augment or provide internal control direction for SAS 70 attestations provided by cloud providers.

簡単に要約すると、これまた別に CSA が出しているセキュリティ・ガイダンスの13のドメインに沿った形で、且つ業界標準であるISO27001/27002やCOBIT、PCI DSS、HIPPAなどとの関係性を含めて各種コントロール仕様をまとめたもの、ということです。
中を見るとわかりますが、 NIST のサービスデリバリモデル( SaaS / PaaS / IaaS ) 毎の適用有無、およびサービスプロバイダ / テナント別の適用有無などかなり詳細にまとまっている資料です。

CSA ガイドラインの13ドメインの中の12番目が「Identity and Access Management」だったり何故か Identity and Access Management に関してだけ別冊があったり、と CSA の中でもアイデンティティ管理はかなり重要視されている領域なので、もちろんこの CCM の中にもアイデンティティ管理に関連する項目が登場します。

先の Office365 での適用状況について少しピックアップしてみたので、紹介してみたいと思います。
(ちなみにベースとなっているのは CCM 1.1 Final 2010/12/17版の様です。現在は1.2が出ています)


  • HR-03 人事 -  雇用の終了
    • 要求
      • 雇用手続きにおいて雇用の終了や変更を行う際の役割や責任に関して、割り当て、文書化、コミュニケーションを行う必要があります。
    • 対応
      • 従業員の雇用終了プロセスは、Microsoft 米国本社の人事ポリシーによって行われます。 
      • 当社がお客様のアカウントを作成することはありません。お客様自身が、Microsoft Online 管理センターで直接アカウントを作成するか、またはローカルの Active Directory 内にアカウントを作成します。それらのアカウントは、Microsoft Online Services と同期することができます。そのため、作成するユーザー アカウントの正確性については、お客様がその責任を負います。
  • IS-07 情報セキュリティ - ユーザー アクセス ポリシー
    • 要求
      • アプリケーション、データベース、サーバー、ネットワーク インフラストラクチャへの通常のアクセス権および特権付きのアクセス権を付与/無効化するためのユーザー アクセスに関するポリシーと手順を文書化し、承認し、実装する必要があります。これは、ビジネス、セキュリティ、コンプライアンス、サービス レベル契約 (SLA) の要件に準拠している必要があります。
    • 対応
      • アクセス制御ポリシーはポリシー全体を構成するコンポーネントの 1 つであり、正式な確認および更新のプロセスが適用されます。Microsoft Online Services の資産に対するアクセス権は、ビジネス要件に基づいて、資産の所有者の承認を得たうえで付与されます。加えて、以下の項目が適用されます。
      • 資産に対するアクセス権は、知る必要性のある人間に限定する原則、および最小特権の原則に基づいて付与されます。
      • 適用可能であれば、役割ベースのアクセス制御を使用して、個人ではなく、特定の職務または責任領域に対して論理的なアクセス権を割り当てます。
      • 物理的および論理的なアクセス制御ポリシーは、規格に準拠します。
      • ISO 27001 規格 (具体的には付属文書 A の項 11) で、"アクセス制御" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。 
  • IS-08 情報セキュリティ - ユーザー アクセスの制限/承認
    • 要求
      • アプリケーション、システム、データベース、ネットワーク構成、および機密度の高いデータや機能に対する通常のユーザー アクセス権や特権付きのユーザー アクセス権は制限される必要があります。また、それらのアクセス権を付与する前に管理者によって承認される必要があります。
    • 対応
      • アクセス制御ポリシーはポリシー全体を構成するコンポーネントの 1 つであり、正式な確認および更新のプロセスが適用されます。Microsoft Online Services の資産に対するアクセス権は、ビジネス要件に基づいて、資産の所有者の承認を得たうえで付与されます。加えて、以下の項目が適用されます。
      • 資産に対するアクセス権は、知る必要性のある人間に限定する原則、および最小特権の原則に基づいて付与されます。
      • 適用可能であれば、役割ベースのアクセス制御を使用して、個人ではなく、特定の職務または責任領域に対して論理的なアクセス権を割り当てます。
      • 物理的および論理的なアクセス制御ポリシーは、規格に準拠します。
      • ISO 27001 規格 (具体的には付属文書 A の項 11.2) で、"ユーザー アクセスの管理と特権の管理" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。  
  • IS-09 情報セキュリティ - ユーザー アクセスの無効化
    • 要求
      • 従業員、契約業者、顧客、ビジネス パートナー、またはサード パーティの状況に何らかの変更があった場合に、組織のシステム、情報資産、およびデータに対するユーザー アクセスの準備解除、無効化、変更のタイムリーな実行を実装する必要があります。こうした状況の変化には、雇用、契約、または合意の終了、雇用状態の変更、組織内での異動などが含まれます。
    • 対応
      • 管理者、およびアプリケーションやデータの所有者は、誰がアクセスしているかを定期的に確認する責任を負います。オンラインのさまざまな場所で、アクセスをチェックするためのツールを入手できます。適切なアクセスの準備が行われていることを検証するために、定期的にアクセスの確認監査が行われます。
      • ISO 27001 規格 (具体的には付属文書 A の項 8.3.3) で、"アクセス権の削除" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。 
  • IS-10 情報セキュリティ - ユーザー アクセスの確認
    • 要求
      • すべてのレベルのユーザー アクセスは、管理者によって計画された間隔で確認され、文書化されます。アクセス違反が見つかった場合は、文書化されているアクセス制御に関するポリシーと手順に従って改善策を実行する必要があります。
    • 対応
      • 管理者、およびアプリケーションやデータの所有者は、誰がアクセスしているかを定期的に確認する責任を負います。オンラインのさまざまな場所で、アクセスをチェックするためのツールを入手できます。Microsoft Online では、提供しているサービスの中でお客様がエンド ユーザーによるアクセスの監査と委任を行うための強化された機能を用意しています。詳細については、対応するサービスの説明を参照してください。
      • ISO 27001 規格 (具体的には付属文書 A の項 11.2) で、"ユーザー アクセスの管理と特権の管理" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。  
  • IS-15 情報セキュリティ - 職務分離
    • 要求
      • 職務の適切な分離を実施、保証するためのポリシー、プロセス、手順を実装する必要があります。興味の制約に関するユーザーの役割の競合が発生する場合は、組織の情報資産の承認されない変更や意図しない変更、または誤使用によって生じるリスクを軽減するための技術的な制御を行う必要があります。
    • 対応
      • Office 365 サービスは、異なるホスティング サービスの開発スタッフ、運用スタッフが職務分離の原則に従うことを必要とします。これにはソース コード、ビルド サーバー、および運用環境に対するアクセス制御が含まれます。例:
        • Office 365 サービスの運用環境に対するアクセスは運用担当者に制限されます。開発チームとテスト チームには、運用環境内から提供された情報に対してアクセス権が与えられる場合があり、問題のトラブルシューティングに役立てることができます。
        • Office 365 サービスのソース コード管理に対するアクセスは開発担当者に制限され、運用担当者がソース コードを変更することはできません。
      • マイクロソフトの担当者は、マルチテナント環境の委託が行われる前にサーバーを構築します。サーバーの構築が完了すると、構築チームは自身のアクセス許可を削除します。サーバーを委託した時点から、マイクロソフトの担当者が委託されたサーバー上で実行されるシステムへのアクセス許可を得ることができる方法は限られています。ヘルプ デスクのスタッフは、アクセスを求めるサービス チケットの直接の結果として、またはソフトウェアのインストールや問題解決のためのシステム更新の直接の結果として、アクセス権を入手する場合があります。このような場合、監査ログによって、誰がいつログインしたかが示されます。マイクロソフトが採用しているプロセスは、保持している認定に準拠しています。
      • 不正行為、誤使用、またはエラーの可能性を最小限に抑えるため、Microsoft Online Services の環境内の機密度の高い機能や重要な機能に対して、職務の分離が実装されています。                     
      • ISO 27001 規格 (具体的には付属文書 A の項 10.1.3) で、"職務の分離" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。
  • SA-02 セキュリティ アーキテクチャー - ユーザー ID 資格情報
    • 要求
      • アプリケーション、データベース、サーバーおよびネットワーク インフラストラクチャにユーザー資格情報およびパスワード制御を (自動化を通じて) 実装および実施します。この場合、以下の最低条件を満たす必要があります。
        • パスワードをリセットする前にユーザー ID を検証する。
        • ユーザー以外の人物 (管理者など) がパスワードのリセットを行った場合、ユーザーが最初に使用する際にパスワードを即座に変更する必要がある。
        • 契約終了となったユーザーのアクセスの無効化をタイムリーに行う。
        • 少なくとも 90 日ごとに、非アクティブなユーザー アカウントを削除または無効にする。
        • 一意のユーザー ID を使用し、グループ、共有、または汎用のアカウントおよびパスワードを禁止する。
        • パスワードの有効期限を 90 日以内にする。
        • パスワードの最小文字数を 7 文字以上にする。
        • 数字とアルファベットの両方を含んだ強力なパスワードを使用する。
        • パスワードの再使用は、少なくとも 4 つのパスワードが使用された後に許可する。
        • ユーザー ID をロックアウトする試行回数は、多くても 6 回までにする。
        • ユーザー ID のロックアウト期間は最低 30 分にするか、管理者がユーザー ID を有効にするまでとする。
        • セッション アイドル時間が 15 分以上経過した場合に、端末を再度アクティブにするには、パスワードを再入力するようにする。
        • 特権付きのアクセスに対するユーザー アクティビティ ログを保持する。
    • 対応
      • Microsoft Online Services では、Active Directory を使用して、パスワード ポリシーの適用状況を管理しています。Microsoft Online Services システムは、強制的にユーザーに複雑なパスワードを使用させるように構成されています。パスワードには最長の有効期限と最小文字数が割り当てられます。
      • Microsoft Online Services が所有されている環境または運用されている環境に関連サービスまたはシステムを導入する場合、その前に契約者提供の既定のパスワードを変更することが、パスワードの取り扱い要件に含まれています。
      • ISO 27001 規格 (具体的には付属文書 A の項 11.2.1 および 11.2.3) で、"ユーザー パスワードの管理およびユーザー登録" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。  
  • SA-07 セキュリティ アーキテクチャー - リモート ユーザーの多要素認証
    • 要求
      • すべてのリモート ユーザー アクセスに対して多要素認証が必要です。
      • 高い保証を必要とする操作には、どの形式の認証を使用しますか。これには、管理インターフェイスへのログイン、キー作成、複数のユーザー アカウントへのアクセス、ファイアウォール構成、リモート アクセスなどが含まれます。
      • ファイアウォールなど、インフラストラクチャ内の重要なコンポーネントを管理する場合に、2 要素認証が使用されていますか。
    • 対応
      • スタッフおよび契約業者のスタッフによる Microsoft Online Services の運用環境へのアクセスは、厳しく制御されています。
      • ターミナル サービス サーバーは、高度な暗号化設定を使用するように構成されています。
      • マイクロソフトのユーザーには、リモート アクセス セッションを確立するために、有効な証明書と有効なドメイン アカウントが含まれているスマートカードが Microsoft Online Services から発行されます。
      • ISO 27001 規格 (具体的には付属文書 A の項 11.4.2) で、"外部接続に対するマイクロソフトのユーザー認証" が規定されています。詳細については、マイクロソフトが認定を取得し、公開されている ISO 規格を確認することをお勧めします。 


関連する項目を抜粋しただけですが結構なボリュームになりますね。これもライフサイクル管理、アクセス制御、認証、職務分掌など様々な角度での要求への対応を行っているためだと言うことが出来ます。

実際に内情がどうなっているかは別として各パブリック・クラウド事業者はこのようなガイドラインへの対応度合を利用者からはかなり厳しくみられる傾向にあるので、今回のように公開文書という形での対応を含め色々と対策を打ってきているように感じます。特にOffice365やGoogleAppsなどはメールやグループウェアという形でかなりの生情報をクラウド上へ配置することになるので、利用者の不安を払しょくすることが最大のポイントになりがちです。
同じような対応をプライベート・クラウドで行おうと思うと結構難しいような気もしますので、国内のクラウド事業者も色々と苦労があるんでしょうね。。と遠い目をしてしまいます。

2011年10月13日木曜日

AD FS2.0 Rollup 1 は Office 365 を強く意識


RTW がリリースされてから1年半程度が経過した AD FS 2.0 ですが、Rollup 1 が現地の 10/12 にリリースされました。

サポートページ:Description of Update Rollup 1 for Active Directory Federation Services (AD FS) 2.0

http://support.microsoft.com/kb/2607496


内容は bug fix の他、Office 365 との連携を強く意識した幾つかの機能拡張がされています。
追加されたのは以下の 4 つの機能で、いずれも AD FS Proxy を公開することを含め( Outlook からの Office 365 アクセスに利用するため )、Office 365 を使うための機能拡張と言えそうです。

  • Multiple Issuer Support
    • これまで、複数のトップレベルドメインが存在する環境( UPN 属性が複数設定されている環境 )で Office 365 / AD FS 2.0 連携を行う場合は各ドメインの単位に AD FS 2.0 サーバを配置する必要がありましたが、この機能拡張により 1台のサーバで対応できる様になりました。まだ検証はしていませんが動きとしてはユーザの UPN 属性によって発行するトークンの Issuer を動的に書き換えるような動きをするそうです。
  • Client Access Policy Support
    • これも Office 365 に絡む話ですが、 Office 365 へアクセスをネットワークの場所などで制限することができる様になっています。例えば、社外からのアクセスをする場合は Office 365 へのアクセスを不可にする、等といった制限ができるようです。
  • Congestion Avoidance Algorithm
    • 特に外部に AD FS Proxy を公開することを意識した機能だと思われますが、高負荷時に認証リクエストの数をしぼることでサービス停止を防ぐための機能を実装しています。
  • Additional AD FS 2.0 performance counters
    • トークン発行要求の数や、認証に失敗した数などがパフォーマンスカウンターで確認できる様になりました。

最近は大企業でも Office 365 / AD FS 2.0 の導入事例が増えてきているようなので、これらの機能の実装で AD FS 2.0 もようやく実用に足るものとなって来たと言えそうです。

2011年10月12日水曜日

salesforce.com summer'11 の JIT Provisioning を試してみる

salesforce.com の summer'11 版の新機能で Just In Time Provisioning(JIT Provisioning)が追加されているのを発見したのでちょっとAD FS2.0との連携動作を確認してみました。

■JIT Provisioning とは
試してみる前にまず、JIT Provisioning とはなんなのか?を簡単に解説しておきます。

一言で言うと「SAML 等の Assertion からユーザを On the Fly で作成する」ということです。これまで一般的にシステムへのシングルサインオンをする前提はそのシステムに「あらかじめ」ユーザが作成されていることが必要でした。しかし、クラウド上のシステムへあらかじめユーザを作成する=クラウド上にユーザ情報をある程度持たせる必要がある、という点に抵抗感があったり、あくまでオンプレミスとクラウドの間で疎なシステム結合を行いたい、というニーズに対して登場してきたのが JIT Provisioning です。 動作としては、例えばSAMLでのシングルサインオンを行うような場合に、IdP から発行されるセキュリティトークンの中にある Assertion (クレーム)を元にユーザを作成する、という動きです。

・従来のプロビジョニング~シングルサインオン






















・JIT プロビジョニング~シングルサインオン




■salesforce.com における JIT Provisioning 設定

では、早速設定を確認してみます。

まずは salesforce.com 側の設定です。今回は force.com を使っていますが、基本的な設定は salesforce.com でも同様です。

基本的な設定方法は以前 @IT に書いた記事を参考に実施をして行くことになります。
 Windowsで構築する、クラウド・サービスと社内システムのSSO環境 第3回  http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso03/adfs2sso03_04.html


記事と異なる点は以下の通りです。

・salesforce 側のシングルサインオン設定  

 Force.com のセキュリティ設定の中のシングルサインオン設定で、以下を設定します。  
 ・ユーザプロビジョニングの有効化:チェック  
 ・SAML のユーザ ID 種別:アサーションには、ユーザオブジェクトの統合 ID が含まれます












・プロファイルの作成  

 JIT Provisioning の前提として、SAML アサーションの Attribute フィールドの中に最低でも  
 ・Username  
 ・Email  
 ・LastName  
 ・ProfileId
 が入っている必要があります。  
 参考)http://login.salesforce.com/help/doc/en/sso_jit_requirements.htm

 UserName や Email などはわかりやすい属性なので、特にこの段階で意識をする必要はありませんが、 ProfileId だけは force.com の管理画面からも見ることが出来ません。(本来は 00ex0000001pBNL などといった識別子のようです)頑張ってAPEX等でコードを書いて実際のIDを取得しても良いのですが、敷居が高いので同じ属性にプロファイル名を入れると force.com 側で勝手に ID へ変換してくれるので今回はそちらを使います。

 ただ、ビルトインのプロファイル名( Force.com - Free User など)はうまく識別をしてくれなかったので、今回は新たに単純に「 User 」という名前のプロファイルを作りました。( Force.com - Free User をテンプレートとして作成したので内容は全く同じです)















・AD FS2.0 側のクレーム発行ルール

 次に AD FS2.0 側ですが、通常の SSO 設定と同様に Active Directory の UPN やメールアドレスを NameIdentifier に入れてあげる点に加え、上記にも書いた JIT Provisioning に必要な各属性に関するルールの記述が必要です。

 その際に、各属性名のプレフィックスに「 User. 」をつけてあげる必要があります。  具体的には、以下の様なマッピングを行います。
発行するクレームタイプデータソース
NameIdentifierActive DirectoryUPN or メールアドレス(今回は UPN を利用)
User.Usernameメールアドレス
User.Emailメールアドレス
User.LastName
User.ProfileId固定値「User」

 Username、Email、LastName についてのクレーム発行ルールはカスタムで以下の様に記述しています。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("User.Username", "User.Email", "User.LastName"), query = ";mail,mail,sn;{0}", param = c.Value);


同様に、ProfileId については以下の様に記述しています。

 => issue(Type = "User.ProfileID", Value = "User", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified");


■実際の動作確認

では、いよいよ動作を確認します。

まず、 force.com 側にあらかじめユーザが存在しないことを確認するためにユーザ一覧を見ておきます。














この状態で Active Directory 上に新規ユーザを作成し、AD FS2.0 で認証後、force.com へアクセスします。IdP Initiated ログオンをしますので、
 https://[AD FS2.0サーバ]/adfs/ls/idpinitiatedsignon.aspx?loginToRp=https://saml.salesforce.com
へのアクセスをします。

 - 新規ユーザ


- AD FS2.0 で認証

















すると、うまくいけばあらかじめプロビジョニングしているわけではないのに、force.com へログインできます。




















では、実際に force.com にユーザが作成されているかどうかを確認するために管理コンソールでユーザ一覧を見てみます。













見事にユーザが出来ています。


■ JIT Provisioning の利点と注意点

 この仕組みの最大の利点はあらかじめプロビジョニングをしておく必要がない= ID 管理システムの構築やアダプタの開発などをしなくても済む、という点です。

 反面、注意しなければならないポイントもあります。 例えば、
 ・ユーザの削除は手動でしなければならない
 ・利用者の数が予測しにくいのでライセンス管理が必要である
 ・ユーザ同士でのコラボレーションをしたくても相手が一度もログインしたことがなければシステム上にユーザが存在しないので情報共有などが出来ない
 などが挙げられます。

 このように万能ではありませんが、別の仕組みや運用と合わせてある程度のガバナンスを保ったうえで利用するには非常に有用な仕組みと言えると思います。