MSC の裏番組ということで流石に大盛況というわけにはいかなかったのですが、いずれリベンジをするかもしれません。
とりあえず見逃した方はどうぞ。
20110929 クラウド連携において企業内ID管理基盤に求められるもの
View more presentations from Naohiro Fujie.
2011年9月29日木曜日
セミナ資料を UP しました
前のエントリで告知させていただいた MSC 裏番組「Active Directory、人任せの運用から脱却しませんか？」で使ったスライドをアップロードしました。
MSC の裏番組ということで流石に大盛況というわけにはいかなかったのですが、いずれリベンジをするかもしれません。
とりあえず見逃した方はどうぞ。
MSC の裏番組ということで流石に大盛況というわけにはいかなかったのですが、いずれリベンジをするかもしれません。
とりあえず見逃した方はどうぞ。
2011年9月27日火曜日
【告知】MSC会場から徒歩10分 - 裏番組「Active Directory、人任せの運用から脱却しませんか？」
直前の告知となりましたが世間が MSC で品川に集まっている裏でこっそりとセミナに登壇します。
[マイクロソフトソリューションセミナー] Active Directory、人任せの運用から脱却しませんか？
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032491546&Culture=ja-JP
アジェンダは以下で、私は後半セッションを担当します。
10:00～11:00 マイクロソフトセッション
クラウドのセキュリティをどうやって守ればよいのでしょうか。暗号化、ログ管理、様々なキーワードが飛び交う中、認証はその中心となる重要な要素です。
認証はセキュリティの基盤であり、ここをおろそかにすると本来権限のないユーザーが自宅やモバイル環境から簡単にアクセスできるようになってしまいます。このセッションでは、
現在の Active Directory を利用しながらクラウド環境へと拡大するために想定しなければならないこと、そして対応策をご紹介します。マイクロソフトのクラウドサービスに限らず、現在クラウドサービスをご利用中の方、ご検討中の方は、必聴です。
11:00～11:45 クラウド連携において企業内 ID 管理基盤に求められるもの（伊藤忠テクノソリューションズ株式会社）
これまで企業内 IT 管理者は Active Directory をはじめとした認証基盤の維持や企業内での展開を中心に検討をしてきました。
しかし、近年パブリック/プライベート問わず社外のクラウド・サービスを利用する流れが勢いを増してきており、IT 管理者はこれまでに加えて異なる対応も行う必要性が出てきています。
本セッションでは具体的にどのような対応が必要となるのかについて ID ライフサイクル管理とID 連携の 2 つの視点で解説します。
11:45～12:00 Q&A
内容としては、AD FS2.0 などでのクラウド／オンプレミスのフェデレーション環境を構築することで何ができるのか？という話と、フェデレーション対象となるアイデンティティ情報を如何にして効率的に管理するか？という観点での Forefront Identity Manager 2010 などを使ったアイデンティティ・ライフサイクル・マネジメントの話をします。
また、企業にアイデンティティ管理システムを導入する際のプロジェクトの効率的な進め方、標準的なプロセス、クラウドならではの注意点などをお話したいと思います。
まだまだ集客中だということなので、MSC の2日目の午前中にちょっと高輪を抜け出して同じく品川のマイクロソフトのオフィスへ暇つぶしにいらしてくださいｗｗ
[マイクロソフトソリューションセミナー] Active Directory、人任せの運用から脱却しませんか？
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032491546&Culture=ja-JP
アジェンダは以下で、私は後半セッションを担当します。
10:00～11:00 マイクロソフトセッション
クラウドのセキュリティをどうやって守ればよいのでしょうか。暗号化、ログ管理、様々なキーワードが飛び交う中、認証はその中心となる重要な要素です。
認証はセキュリティの基盤であり、ここをおろそかにすると本来権限のないユーザーが自宅やモバイル環境から簡単にアクセスできるようになってしまいます。このセッションでは、
現在の Active Directory を利用しながらクラウド環境へと拡大するために想定しなければならないこと、そして対応策をご紹介します。マイクロソフトのクラウドサービスに限らず、現在クラウドサービスをご利用中の方、ご検討中の方は、必聴です。
11:00～11:45 クラウド連携において企業内 ID 管理基盤に求められるもの（伊藤忠テクノソリューションズ株式会社）
これまで企業内 IT 管理者は Active Directory をはじめとした認証基盤の維持や企業内での展開を中心に検討をしてきました。
しかし、近年パブリック/プライベート問わず社外のクラウド・サービスを利用する流れが勢いを増してきており、IT 管理者はこれまでに加えて異なる対応も行う必要性が出てきています。
本セッションでは具体的にどのような対応が必要となるのかについて ID ライフサイクル管理とID 連携の 2 つの視点で解説します。
11:45～12:00 Q&A
内容としては、AD FS2.0 などでのクラウド／オンプレミスのフェデレーション環境を構築することで何ができるのか？という話と、フェデレーション対象となるアイデンティティ情報を如何にして効率的に管理するか？という観点での Forefront Identity Manager 2010 などを使ったアイデンティティ・ライフサイクル・マネジメントの話をします。
また、企業にアイデンティティ管理システムを導入する際のプロジェクトの効率的な進め方、標準的なプロセス、クラウドならではの注意点などをお話したいと思います。
まだまだ集客中だということなので、MSC の2日目の午前中にちょっと高輪を抜け出して同じく品川のマイクロソフトのオフィスへ暇つぶしにいらしてくださいｗｗ
2011年9月24日土曜日
Microsoft が BHOLD を買収
次期リリースである 2010 R2 がようやく見えてきた Forefront Identity Manager ですが、実はその後の機能拡張の方向性ってあんまり明確じゃないんです・・・。
と、ここに来て Microsoft の BHOLD の買収のニュースが流れてきました。
http://www.microsoft.com/pathways/bhold/default.htm
この BHOLD という会社ですが、これまでも FIM 2010 用のレポーティングツールである BHOLD Reporting for Microsft Forefront Identity Manager 2010 を出していたり、BHOLD Attestation や BHOLD Controls for IT Auditors などといった監査系のソリューションを強みにしている会社です。
まだ具体的にどのような機能が FIM に統合されていくのかについては「More information will be disclosed at a future date.」とのことですが、買収発表のページに現在の BHOLD 製品が FIM にアドオンとして、
・Managing access rights of people by role to achieve business goals while minimizing risk
・Increasing end user productivity through self-service role management and access recertification
・Aiding in risk management and GRC initiatives with respect to identities and their associated access rights
といった機能を提供していることが紹介されていますので、このあたりの機能は最低限盛り込まれていくことになるのでは？と思います。
2010 R2 での System Center Service Manager でのレポーティング機能の提供に加えて、BHOLD の持つテンプレートや Attestation 機能が盛り込まれれば、ようやく一通りの機能がビルトインされた製品スイートとして完成されていくことになる気がしますｗ
気になるのは、価格がどうなるか、そして、どんどん必要なサーバ台数が増えること、ですね。R2 での SCSM 統合にしても使おうとすると別に DWH サーバが必要になったりするのがハードルを上げてしまってると思いますので。
と、ここに来て Microsoft の BHOLD の買収のニュースが流れてきました。
http://www.microsoft.com/pathways/bhold/default.htm
この BHOLD という会社ですが、これまでも FIM 2010 用のレポーティングツールである BHOLD Reporting for Microsft Forefront Identity Manager 2010 を出していたり、BHOLD Attestation や BHOLD Controls for IT Auditors などといった監査系のソリューションを強みにしている会社です。
まだ具体的にどのような機能が FIM に統合されていくのかについては「More information will be disclosed at a future date.」とのことですが、買収発表のページに現在の BHOLD 製品が FIM にアドオンとして、
・Managing access rights of people by role to achieve business goals while minimizing risk
・Increasing end user productivity through self-service role management and access recertification
・Aiding in risk management and GRC initiatives with respect to identities and their associated access rights
といった機能を提供していることが紹介されていますので、このあたりの機能は最低限盛り込まれていくことになるのでは？と思います。
2010 R2 での System Center Service Manager でのレポーティング機能の提供に加えて、BHOLD の持つテンプレートや Attestation 機能が盛り込まれれば、ようやく一通りの機能がビルトインされた製品スイートとして完成されていくことになる気がしますｗ
気になるのは、価格がどうなるか、そして、どんどん必要なサーバ台数が増えること、ですね。R2 での SCSM 統合にしても使おうとすると別に DWH サーバが必要になったりするのがハードルを上げてしまってると思いますので。
2011年9月20日火曜日
ACS の Facebook 連携利用ガイド
先日の OpenID Technight vol.8 @ 大阪でも触れましたが、時間もなかったので簡単にしか話が出来なかったので、振り返りつつ解説をしていきたいと思います。
■ACS の機能のおさらい
AppFabric ACS v2 は Windows Azure 上にデプロイされたクラウド上の STS / Federation Provider です。主な機能は「外部 Identity Provider から発行されたセキュリティ・トークンの形式を変換して、要求元のアプリケーションへ渡すゲートウェイ機能」であり、対応するプロトコルとしては ws-federation、OpenID、OAuth2.0 などがあります。
ざっくりいうと Yahoo!やGoogle、facebookなどで発行されたセキュリティ・トークンを ws-federation に乗せた SAML トークンとして Windows Identity Foundation（WIF）を使った .NET アプリケーションへ渡す、という役割を持ちます。
このことによって各 .NET アプリケーションは Yahoo! や Google に対応する形で個別のコードを記述する必要がなくなり開発効率があがる、というのが最大の利点といえます。
■ACS の機能のおさらい
AppFabric ACS v2 は Windows Azure 上にデプロイされたクラウド上の STS / Federation Provider です。主な機能は「外部 Identity Provider から発行されたセキュリティ・トークンの形式を変換して、要求元のアプリケーションへ渡すゲートウェイ機能」であり、対応するプロトコルとしては ws-federation、OpenID、OAuth2.0 などがあります。
ざっくりいうと Yahoo!やGoogle、facebookなどで発行されたセキュリティ・トークンを ws-federation に乗せた SAML トークンとして Windows Identity Foundation（WIF）を使った .NET アプリケーションへ渡す、という役割を持ちます。
このことによって各 .NET アプリケーションは Yahoo! や Google に対応する形で個別のコードを記述する必要がなくなり開発効率があがる、というのが最大の利点といえます。
■ACS の Facebook 連携とは
ACS の Facebook 連携は OAuth2.0 が利用されています。具体的に言うと、Facebook の認可サーバ（AuthZ Server）からアクセス・トークンを取得するのがここで言う連携の最大の目的であり実体です。
以下の図でいう OAuth AuthZ Server / OAuth Resource Server が Facebook に当たります。ACS は Facebook からアクセス・トークンを取得しています。
ACS の Facebook 連携は OAuth2.0 が利用されています。具体的に言うと、Facebook の認可サーバ（AuthZ Server）からアクセス・トークンを取得するのがここで言う連携の最大の目的であり実体です。
以下の図でいう OAuth AuthZ Server / OAuth Resource Server が Facebook に当たります。ACS は Facebook からアクセス・トークンを取得しています。
■混同しやすい点
ここが最大の注意点なのですが、Yahoo! や Google、オンプレミスの AD FS2.0 との連携に使われる OpenID や ws-federation といったプロトコルと OAuth2.0 は若干性質が違います。
例えば ACS の Google 連携 では（おそらく）OpenID Authentication を利用しているのであくまで認証の外部化を目的としていますし、AD FS2.0 との連携では ws-federation を利用しているので認証およびクレームの伝搬を目的としています。
しかし、Facebook 連携に使用している OAuth2.0 は基本的には「保護されたリソースへアクセスするための認可を受けること」を目的としています。つまり、認証自体を目的としている訳でも、Facebook 上の属性をクレームとして伝搬することを目的としている訳でもありません。
ただ、結果として ACS を経由することで .NET アプリケーションは個別に認証機能を実装する必要はなくなりますし、ある程度のクレーム情報については取得することが出来てしまいますので、認証を受けて名前やメールアドレスを取得する、という目的での利用をすることも可能ではある訳です。
Facebook から取得したクレーム
■Facebook 連携の使い方
では、本来（？）のACS / Facebook 連携の使い方、というより OAuth の使い方はどのような物なのでしょうか？
先ほどの Facebook から取得したクレームの中に claimType が http://www.facebook.com/claims/AccessToken となっている物がありました。これが ACS が Facebook から取得したアクセス・トークンです。
本来は Facebook の保持するリソースに対して API アクセスを行うために Facebook の認可サーバがクライアント（RESTful Web Service）に対して払い出すのがこのアクセス・トークンであり、ACS の Facebook 連携においては ACS が Facebook から見てクライアントとなります。
しかし、一番最初に書いた通り、ACS は「ゲートウェイ」なので、Facebook から取得したアクセス・トークンを SAML トークンの1つの Assertion として変換し、ws-federation プロトコルに乗せて WIF を使った .NET アプリケーションへ渡します。
それが、先にも出したこの図の左半分です。
ここが最大の注意点なのですが、Yahoo! や Google、オンプレミスの AD FS2.0 との連携に使われる OpenID や ws-federation といったプロトコルと OAuth2.0 は若干性質が違います。
例えば ACS の Google 連携 では（おそらく）OpenID Authentication を利用しているのであくまで認証の外部化を目的としていますし、AD FS2.0 との連携では ws-federation を利用しているので認証およびクレームの伝搬を目的としています。
しかし、Facebook 連携に使用している OAuth2.0 は基本的には「保護されたリソースへアクセスするための認可を受けること」を目的としています。つまり、認証自体を目的としている訳でも、Facebook 上の属性をクレームとして伝搬することを目的としている訳でもありません。
ただ、結果として ACS を経由することで .NET アプリケーションは個別に認証機能を実装する必要はなくなりますし、ある程度のクレーム情報については取得することが出来てしまいますので、認証を受けて名前やメールアドレスを取得する、という目的での利用をすることも可能ではある訳です。
Facebook から取得したクレーム
■Facebook 連携の使い方
では、本来（？）のACS / Facebook 連携の使い方、というより OAuth の使い方はどのような物なのでしょうか？
先ほどの Facebook から取得したクレームの中に claimType が http://www.facebook.com/claims/AccessToken となっている物がありました。これが ACS が Facebook から取得したアクセス・トークンです。
本来は Facebook の保持するリソースに対して API アクセスを行うために Facebook の認可サーバがクライアント（RESTful Web Service）に対して払い出すのがこのアクセス・トークンであり、ACS の Facebook 連携においては ACS が Facebook から見てクライアントとなります。
しかし、一番最初に書いた通り、ACS は「ゲートウェイ」なので、Facebook から取得したアクセス・トークンを SAML トークンの1つの Assertion として変換し、ws-federation プロトコルに乗せて WIF を使った .NET アプリケーションへ渡します。
それが、先にも出したこの図の左半分です。
後は、 .NET アプリケーションが受け取ったアクセス・トークンを使って Facebook の API へアクセスしリソースの取得や各種操作を行う、というのが本来の Facebook 連携を行う意味合いに沿った使い方、ということになります。
例えば、Facebook から誕生日情報を取得したければ、例えば以下の様なコードを書くことになります。
内容ですが、Facebook の graph API （http://graph.facebook.com）に対して自分の誕生日（me?fields=birthday）を取得したアクセス・トークンをパラメータとして付与（access_token=[ACS より取得したアクセス・トークン]）して HTTP/GET する、というものです。
結果、json 形式で誕生日の文字列が返却されますので、例では Dynamic JSON（http://dynamicjson.codeplex.com/）を使って文字列をパースしてテキストボックスに表示をさせています。
同様に Facebook のウォールへの投稿の例です。
今度は HTTP/POST メソッドを利用した例ですが、考え方は同じで ACS から取得したアクセス・トークンおよび投稿したいメッセージを graph API の me/feed に与える、というやり方です。
■アクセス・トークンの扱いについて
ここまで ACS の Facebook 連携の使い方について整理をしてきましたが、1点注意をすべき点としてアクセス・トークンの取り扱いがあります。
これは OAuth を使ったアプリケーション全般に言えますが、取得したアクセス・トークンはあくまで文字列なので他のアプリケーションから再利用することが出来てしまいます。その意味でアクセス・トークンは Facebook のリソースへアクセスするための「合鍵」と言うことが出来ます。
例えば、取得したアクセス・トークンをコピーして全く別のアプリケーションから Facebook のリソースへアクセスすることも出来てしまいます。
フォームアプリケーションに取得したアクセス・トークンをコピーして Facebook のリソースへアクセスする例
例えば、Facebook から誕生日情報を取得したければ、例えば以下の様なコードを書くことになります。
| var f_birthday = new WebClient().DownloadString(@"https://graph.facebook.com/me?fields=birthday&access_token=" + [ACS より取得したアクセス・トークン]); var json = DynamicJson.Parse(f_birthday); TextBox1.Text = json.birthday; |
内容ですが、Facebook の graph API （http://graph.facebook.com）に対して自分の誕生日（me?fields=birthday）を取得したアクセス・トークンをパラメータとして付与（access_token=[ACS より取得したアクセス・トークン]）して HTTP/GET する、というものです。
結果、json 形式で誕生日の文字列が返却されますので、例では Dynamic JSON（http://dynamicjson.codeplex.com/）を使って文字列をパースしてテキストボックスに表示をさせています。
同様に Facebook のウォールへの投稿の例です。
| System.Collections.Specialized.NameValueCollection ps = new System.Collections.Specialized.NameValueCollection(); ps.Add("access_token", [ACS から取得したアクセス・トークン]); ps.Add("message", [投稿したいメッセージ]); WebClient wc = new WebClient(); byte[] resData = wc.UploadValues(@"https://graph.facebook.com/me/feed", ps); wc.Dispose(); |
今度は HTTP/POST メソッドを利用した例ですが、考え方は同じで ACS から取得したアクセス・トークンおよび投稿したいメッセージを graph API の me/feed に与える、というやり方です。
■アクセス・トークンの扱いについて
ここまで ACS の Facebook 連携の使い方について整理をしてきましたが、1点注意をすべき点としてアクセス・トークンの取り扱いがあります。
これは OAuth を使ったアプリケーション全般に言えますが、取得したアクセス・トークンはあくまで文字列なので他のアプリケーションから再利用することが出来てしまいます。その意味でアクセス・トークンは Facebook のリソースへアクセスするための「合鍵」と言うことが出来ます。
例えば、取得したアクセス・トークンをコピーして全く別のアプリケーションから Facebook のリソースへアクセスすることも出来てしまいます。
フォームアプリケーションに取得したアクセス・トークンをコピーして Facebook のリソースへアクセスする例
このようなことを防ぐためにもアプリケーション開発者は取得したアクセス・トークンが外部に漏れないように保護することが必要です。
また、これも当然ですが ACS に設定する Facebook へのアクセス許可の範囲については必要最低限に絞っておくことが肝要です。
また、これも当然ですが ACS に設定する Facebook へのアクセス許可の範囲については必要最低限に絞っておくことが肝要です。
尚、アプリケーションの許可フィールドに設定可能な Facebook の Permission 一覧は以下のページを参照してください。（Facebook へのログインが必要です）
http://developers.facebook.com/docs/reference/api/permissions/
■参考資料
・ACS / Facebook 連携手順
MS 安納さんの資料
https://skydrive.live.com/?cid=2bd8b3552eedd654&sc=documents&id=2BD8B3552EEDD654%214073
・OpenID / OAuth の違い
NRI 崎村さんの blog
http://www.sakimura.org/2011/05/1087/
■おまけ
最後に先日の OpenID Technight の資料をアップしておきます。
http://developers.facebook.com/docs/reference/api/permissions/
■参考資料
・ACS / Facebook 連携手順
MS 安納さんの資料
https://skydrive.live.com/?cid=2bd8b3552eedd654&sc=documents&id=2BD8B3552EEDD654%214073
・OpenID / OAuth の違い
NRI 崎村さんの blog
http://www.sakimura.org/2011/05/1087/
■おまけ
最後に先日の OpenID Technight の資料をアップしておきます。
Openid technight 20110909_fujie
View more presentations from Naohiro Fujie
2011年9月16日金曜日
Claim-Based Identity and Access Control の第2版がリリース
ずっとベータ版だった Microsoft Patterns & Practices の A Guide to Claim-Based Identity and Access Control の第2版がリリースされました。
※ちなみに第1版は書籍化もされ Amazon でも購入可能です。
また、日本語化されて technet で公開されています。
http://technet.microsoft.com/ja-jp/library/gg457904.aspx
以下のURLで参照およびサンプルコードのダウンロードが可能です。
http://msdn.microsoft.com/en-us/library/ff423674.aspx
さて、気になる内容ですが大幅に増強されています。
以下が第1版、第2版それぞれの目次です。
第1版
※ちなみに第1版は書籍化もされ Amazon でも購入可能です。
また、日本語化されて technet で公開されています。
http://technet.microsoft.com/ja-jp/library/gg457904.aspx
以下のURLで参照およびサンプルコードのダウンロードが可能です。
http://msdn.microsoft.com/en-us/library/ff423674.aspx
さて、気になる内容ですが大幅に増強されています。
以下が第1版、第2版それぞれの目次です。
第1版
第2版
大きくは、
・Windows Azure Access Control Service
・SharePoint
・RESTful Web Service
・Windows Phone
といったキーワードに関する記述が新たに増えています。
現在開催中の//build/での Windows 8 の発表にあった Windows LiveID での OS ログインや、LiveID に絡めることで デバイス間でのトークンのローミングを実現する Credentials Vault など今後も色々な機能が続々とリリースされることになりそうなので、要注目です。
・Windows Azure Access Control Service
・SharePoint
・RESTful Web Service
・Windows Phone
といったキーワードに関する記述が新たに増えています。
現在開催中の//build/での Windows 8 の発表にあった Windows LiveID での OS ログインや、LiveID に絡めることで デバイス間でのトークンのローミングを実現する Credentials Vault など今後も色々な機能が続々とリリースされることになりそうなので、要注目です。