Quantcast
Channel: IdM実験室
Viewing all 771 articles
Browse latest View live

[Office365/AD FS2.0] クライアント・アクセス・ポリシー・ビルダー

$
0
0

Office365 を AD FS2.0 と連携された環境で使う最大のメリットはオンプレミスの Active Directory とのシングルサインオンですが、他にも細かなアクセス制御を行うことが出来る、という重要なメリットがあります。
※AD FS2.0 Rollup 1 以降(Rollup 1 についてはこちら


例えば、先月公開された Directory Services Team の blogでは、

  • 社内ネットワーク以外からは Outlook 経由でメールを見れなくする
  • 特定のセキュリティグループに属するアカウントに ActiveSync を使わせない
  • 特定のセキュリティグループに属するアカウントは社内ネットワーク以外から OWA を使わせない
  • 全 OWA ユーザにフォーム認証を強制する

というシナリオに応じた AD FS2.0 の Claim ルール(要求規則)を記載しています。

また、簡単なアクセスポリシーを GUI で設定するためのツールである「クライアント・アクセス・ポリシー・ビルダー」が Technet の Script Center で公開されています。

 - Client Access Policy Builder
  http://gallery.technet.microsoft.com/scriptcenter/Client-Access-Policy-30be8ae2


設定可能なアクセスポリシーは以下の通りです。

■アクセスポリシー

  • 社外ネットワークから Office365 へアクセスさせない
  • 社外ネットワークから Office365 へアクセスさせない(ActiveSync を除く)
  • 社外ネットワークから Office365 へアクセスさせない(OWA や SharePoint Online の様なブラウザベースのアプリケーションを除く)
  • 社外ネットワークから Office365 へアクセスさせない(特定のセキュリティグループのメンバとなっている場合)
  • 社外ネットワークから Office365 へアクセスさせない(Outlook クライアントからのアクセスの場合)


■社外ネットワークの定義

  • 単一のIPアドレス
  • IPアドレスの範囲



使い方は非常に簡単で、上記 URL からダウンロードできる PowerShell スクリプトを AD FS2.0 サーバで実行すると GUI が起動するので、[Create Rules for Claim Types] をクリックすると AD FS2.0 上に Claim Rule を作成し、あとは使いたいポリシーの選択、社外ネットワークのアドレスを設定するだけです。


ポリシーを設定後、画面右下の[build]ボタンをクリックすると AD FS2.0 上に Claim Rule が作成されます。



尚、以下の様な注意点があります。

  • 外部からダウンロードした PowerShell ファイルなので、Set-ExecutionPolicy -Unrestricted を実行して本ツールを起動出来る様にする(実行後は制限を元に戻すことをおすすめします)
  • AD FS2.0 の管理コンソールが起動しているとツールが使えないので、管理コンソールは落とした状態で使う必要がある
  • 念のため、本ツールを使う前に既存の Claim Rule はバックアップしておく方が好ましい



Claim 記述言語は結構ややこしいので、このような GUI ツールを使って設定するのが確実だと思います。
他の汎用ルールについてもこのような GUI ツールが出てくると良いですね。


Windows Azure Active Directory Developer Preview が公開

$
0
0

European Identity Conference の Keynote で Kim Cameron氏が語った Microsoft の IDMaaS(Identity Management as a Service)の実現である Windows Azure Active Directory の Developer Preview がアナウンスされました。

 - Windows Azure Team blog
   Announcing the Developer Preview of Windows Azure Active Directory
   http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx

 - Vibro.NET / Vittorio Bertocci
   Single Sign On with Windows Azure Active Directory: a Deep Dive
   http://blogs.msdn.com/b/vbertocci/archive/2012/07/12/single-sign-on-with-windows-azure-active-directory-a-deep-dive.aspx


あわせて、各種ドキュメントやサンプルツールなどもリリースされています。

 - MSDN ドキュメント
   http://msdn.microsoft.com/en-us/library/hh974476

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

 - Graph Explorer / テスト用ツール
   https://graphexplorer.cloudapp.net


更に興味深いのが Kim Cameron 氏が 最新の blog エントリ「Yes to SCIM. Yes to Graph.」で語っている Graph API と SCIM(Simple Cloud Identity Management)の関係です。


エントリの中で Kim 氏は基本的に SCIM の目指しているゴールをサポートしており、マイクロソフトとして取り組みを支援する姿勢を見せています。

しかし、何故マイクロソフトは SCIM を採用せずに Graph API を検討しているのか?という疑問に対する解として以下の2点を挙げています。

1.多様なオブジェクトが相互に多様な関係性の中に存在する環境において Graph API は検索や操作性において統合されたアプローチを提供するため。

 つまり、SCIM で提供されているスコープ(現状はユーザとグループオブジェクト)以上のオブジェクトと複雑な関係性を表現する上では Graph API の方が向いている、ということでしょうか。

2.巨大なスケールにおいてディレクトリは「多次元ネットワークを表現するものに変化する」ため。

 今後のディレクトリ内にストアされるオブジェクトは全てにつながり、多くのディメンジョンを持つことになるため、 オブジェクトを扱うためには Graph API が必要だ、ということでしょうか。
 例として、レガシーなディレクトリは組織や人やグループなどのオブジェクトを持っていて、組織は人を含み、グループは階層化されている、という様な構造を持っていましたが、ソーシャル構造を表現する必要が出てきている、という話が挙げられており、レガシーな単一指向性のディレクトリでは構造を表現することが不可能になってきている、という主張なのだと思います。


Kim Cameron 氏は次の blog エントリでも Windows Azure Active Directory のリリースについて書く、と宣言しているのでしばらくは目が離せそうにありません。

[WAAD]Graph API で Office365 アカウントを管理する

$
0
0

Windows Azure Active Directory(WAAD)は Office365 などで利用されるマイクロソフトのオンライン・ディレクトリ・サービスです。
ということは Office365 のユーザ情報は WAAD 内にストアされており、Graph API で管理することが出来る、ということになります。

早速、Office365 のユーザの情報を Graph API で取得してみたいと思います。

まず当然ですが Office365 上にユーザを作っておきます。


このユーザ情報を Graph API を試すためのツールである Graph Expolorerを使って取得してみます。

このツールの Resource の値に
  - https://directory.windows.net/sub02adfs.onmicrosoft.com/Users
という形で対象ドメインと取得リソースを指定すれば値が取得できるはずです。



早速、GET をクリックしてみると、、、当然認証が走ります。

この中の Principal Id とか Symmetric Key とは何を指しているのかが、よくわかりません。

このあたりのドキュメントを読むと Graph API を使うには Service Princial を作成するという作業が必要の様です。
 - How-to Procedure: Authenticate To Windows Azure AD Graph Using Windows Azure AD Access Control
   http://msdn.microsoft.com/en-us/library/hh974468

具体的には Office365 の Powershell コマンドレットを使って Service Principal Id を取得するスクリプトを実行する必要があります。
※事前に Microsoft Online Servies サインインアシスタントも必要


ただ、面倒なので既に用意されているスクリプトを使いましょう。
 - PowerShell authorization script
   http://iddemo.blob.core.windows.net/files/CreateServicePrincipal.ps1

上記は直リンクですが、CodePlex で公開されているサンプルアプリケーションの中にもスクリプトが含まれていますので、そちらを利用しても良いでしょう。

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

この中の「C#\PowerShell Scripts」の中に、CreateServicePrincipal.ps1 が上記からダウンロードできるスクリプトと同じものです。


このスクリプトを実行すると Service PrincipalName の指定するように要求されるので、任意の名前を入力します。

Windows Azure Active Directory 内でのユニーク性のチェックが行われ、問題なければマイクロソフト・オンライン・サービスの認証が走り、4つの値が払い出されます。

・Company ID
・AppPrincipal ID
・App Principal Secret
・Audience URI

この値の中の、AppPrincipal ID が先ほどの Graph Explorer の Principal Id、App Principal Secret が Symmetric Key に対応しているので、先ほどのログイン画面でその値を入力しログオンするとユーザの情報が表示されます。
※他の値については SSO を行う際に使うものなのでそのうち紹介したいと思います。


さきほど Office365 上に作ったユーザも確認できます。


今回は単に一覧を表示するだけでしたが、当然追加・変更・削除も出来るので、今後は Office365 へのプロビジョニングを DirSync に頼らなくても出来る様になってくると思います。
TechEd North America のセッションを見ていると既に FIM 2010 用の Graph API Management Agent を開発している会社もあるようなので、より柔軟にオンライン・アカウントを管理出来る様になってくると思います。


[FIM2010] R2 向け Best Practices Analyzer がリリース

$
0
0
これは一度でも FIM をインストール・設定したことがある人なら理解できると思いますが、インストールや設定に際してかなり細かい設定項目や前提事項が存在しています。

真面目にやろうとすると、このような本を片手に頑張ることになるのですが、中々面倒くさいのも事実です。



通常私達がセットアップをする場合は、そのあたりをまとめたスクリプトや設定テンプレートを使ってしまうのですが、結果を一括で確認できるという点では今回リリースされた様な Best Practices Analyzer はとても便利です。

ダウンロード URL

尚、このツールを使うには事前に MBCA2.0(Microsoft Baseline Configuration Analyzer)をインストールしておく必要があります。

ダウンロード URL


早速使ってみます。

まずは起動して Select Product より Forefront Identity Manager 2010 R2 BPA を選択して Start Scan をクリックします。


次の画面で分析対象のパラメータを設定します。今回の環境では CLM および BHOLD は使っていないのでチェックを入れていません。


Start Scan をクリックすると分析が開始され、しばらくすると結果が表示されます。
ここでは、FIMService / FIMSyncService のアカウントのバッチジョブとしてのログオン拒否のポリシーが有効化されていない点と SQL Server Agent のジョブが有効になっていない点がエラーおよび警告として表示されています。


結果をクリックすると詳細が表示され、対応方法について記載された Web サイトへのリンクも用意されています。


では、分析結果で指摘された事項を修正していきます。
まずはサービスアカウントがバッチジョブとしてログオンできない様にポリシーを構成します。


次に SQL Server Agent のジョブで一部有効化されていないものがあったので有効化しておきます。


構成したら再度、ツールで分析をしてみます。
すると今度は問題が表示されなくなります。



みなさんも設定が一通り完了したら一度このツールを使って正しく設定されているかを最後に確認してみることをお勧めします。


[告知]8月~9月はアイデンティティ系イベント三昧

$
0
0

8月~9月は何故かアイデンティティ系のイベントがてんこ盛りです。
私も下記のイベントで都合4回登壇する予定です。

8/28
OpenID Technight Vol.9
http://atnd.org/events/31320
#既にキャンセル待ち

前半に先日のCloud Identity Summitの内容の紹介など非常に興味深いセッションがあった後、「クラウド・アイデンティティとコンシュマライゼーション」というテーマでパネルディスカッションがあり、私は後半のパネルに登場する予定です。

9/19 大阪、9/21 東京
ID & IT Management Conference 2012
http://nosurrender.jp/idit2012/

今年で2回目の開催となる国内では非常に貴重なアイデンティティに関するカンファレンスです。このイベントはパネルディスカッションが中心になっているが特長で、今回私は「シングルサイオンベンダーによる最新技術動向について」というパネルのモデレータを務める予定です。

9/22
.NETラボ勉強会
http://www.dotnetlab.net/dnn/Events/NET%E3%83%A9%E3%83%9C%E5%8B%89%E5%BC%B7%E4%BC%9A2012%E5%B9%B409%E6%9C%88/tabid/122/Default.aspx
#登録サイトは未オープン。オープン時にお知らせします。

.NETラボの高尾さんを巻き込んで遂に企画してしまいました。FIM/ADFS のハンズオンです。日本マイクロソフトからお馴染み安納さんやソフィアネットワークスの国井さん(Directory ServiceのMVP)にも色々とお願いをしてしまったので、かなりレアなイベントになりそうです。

お時間の許す方は是非!

[FIM2010]Google Apps MAをリリースしました

$
0
0
以前のエントリで宣言してそのまま放置していた ECMA2.0 対応の GoogleApps 用管理エージェントですが、先ほど CodePlex 上でリリースしました。

CodePlex 上のプロジェクト



昔 Sourceforge に公開していた ECMA 1.0 用のものと基本的な動きは同じですが、 ECMA2.0 対応をするに際してゼロから書き直しました。
※ FIM 2010 rollup2 より前の ECMA2.0 非対応環境で使う場合は昔のバージョンを使ってください。


ソースコードも一緒に公開しているので、わかる人はわかるとは思いますが、そのうち内容の解説を本ブログ上でも行いたいと思います。


また、前のエントリでも紹介した 9/22 の .NET ラボ勉強会でのハンズオンではこの管理エージェントを使って実際に Google Apps へのプロビジョニングを体験していただこうと思いますのでこちらもお楽しみに。

[FIM2010] R2対応書籍が発売

$
0
0

濃い本が発売されました。

Kent Nordstrom さんによる Microsoft Forefront Identity Manager 2010 R2 Handbook です。




Amazonもしくは Packt Publishingで購入可能です。
※今日現在、Amazon(日本、US共に) では予約販売になっています。

早速購入してみたので、中身を軽く紹介しておきます。

まず、目次は下記の通りです。

Chapter 1: The Story in this Book
Chapter 2: Overview of FIM 2010 R2
Chapter 3: Installation
Chapter 4: Basic Configuration
Chapter 5: User Management
Chapter 6: Group Management
Chapter 7: Self-service Password Reset
Chapter 8: Using FIM to Manage Office 365 and Other Cloud Identities
Chapter 9: Reporting
Chapter 10: FIM Portal Customization
Chapter 11: Customizing Data Transformations
Chapter 12: Issuing Smart Cards
Chapter 13: Troubleshooting


インストールからカスタマイズまで全体的に網羅されています。
特に第8章では Office365 のユーザを管理する方法についての記載があったり、UAG と FIM を使って OTP(ワンタイムパスワード)を使った Office365 へのログオンの記述もあります。
同様に R2 からの新機能である Web ベースの SSPR(セルフサービスパスワードリセット)や SCSM を使ったレポーティングについても記載されています。

残念なのは約400ページで上記のすべてを詳細に解説するのは紙面上無理があり、それぞれの項目についての記述レベルは割と軽いものになっている点です。
しかし、全体に網羅されているので初めて FIM 2010 / FIM 2010 R2 を導入する人にとっては非常に理解しやすい内容になっていると思います。


これを機に日本が誇る?青本も R2 対応してリニューアルしないかなぁ・・・と思っています。

[FIM2010] R2 向け HotFix がリリース

$
0
0

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

修正内容の詳細は
 http://support.microsoft.com/?id=2734159
に記載されていますが、特に日本語環境で重要な修正点としては以下の2点かと。

・Unicode 文字列が含まれるユーザがパスワードリセットポータルを使えなかった不具合を修正
・Synchronization Manager が Unicode 文字列を含むファイルやフォルダへのアクセスができない不具合を修正

いずれもレアケースだとは思うので、それほど影響はありませんが極まれに日本語の sAMAccountName で構成されている Active Directory を見たりするので条件に合致するユーザもいるんだと思います。


他にも Exchange 2010 で Active Sync デバイスを追加したとき、Active Directory からユーザをデプロビジョニングできなくなる、といった課題にも対応したり、パフォーマンス向上をしていたりするようなので、気になる方は適用するとよいと思います。

告知:9/22 ADFS/FIMハンズオン登録開始

9/22 FIM/AD FSセミナの内容をチラっと

$
0
0
前回の投稿で告知させていただいた9/22のFIM/AD FSのセミナですが、ようやく資料とハンズオン環境の作成が一段落してきたので、チラっと。

登録ページはこちら。
http://kokucheese.com/event/index/51905/


この中の私のパートである、「FIM/ADFSのアーキテクチャ(仕組み)解説」ですがこんな目次です。



とりあえず、アイデンティティとかアイデンティティ管理とは何なのか?というあたりの基礎的なところを軽くお話し、その後 FIM と AD FS2.0 の仕組みを解説します。

FIM の仕組みの部分では、一番わかり難い(と思われる)同期規則がユーザにどのように火も付けられるのか?というあたり(コードレス・プロビジョニング)の仕組みを解説予定です。



AD FS 2.0 のパートは AD FS 2.0 自体が非常にシンプルな作りなので、どちらかと言うと SAML そのものの解説になる予定です。



とりあえずこんな感じで進めるので、ぜひご参加を。

[WAAD] Preview ポータルのLook & Feel

$
0
0
Windows Azure Active Directory の管理ポータルの Preview 版が出てきています。

https://activedirectory.windowsazure.com


今後はこのポータルから Office 365 などを含むアカウントの管理や設定を行うことになると思いますので、新しいポータルに慣れておきたいところです。

ということで、新旧ポータルの画面を単純に並べて比較しておきます。
(旧: Office365 の管理者ポータル。新: Windows Azure Active Directory 管理ポータル Preview)

トップ画面

【旧】

【新】今は Office365 の情報しか出ていませんが、今後は他のサービスに関する情報も表示されることになるんでしょうか。 ※ Windows Intune / Dynamics Online は触ったことがないので、今でもここに出てくるかは不明です。どなたか知ってますか?


ユーザ

【旧】


【新】シングルサインオンやディレクトリ同期が別メニューへ移動したので非常にシンプルになっています。

セキュリティグループ

【旧】

【新】

ドメイン

【旧】

【新】この辺りはあんまり変わりません。


シングルサインオンなど

旧ポータルではユーザの管理の中にあったメニューが「統合」メニューに別出しされています。

【新】すっきりしました。


と、ざっと並べてみました。
今後は新しいポータルで管理を行うことになると思いますので、早めに慣れておきましょう。
(という程違いはありませんが。。)

[WAAD]スタンドアロンのテナントが作成可能に

$
0
0

これまでは Windows Azure Active Directory(WAAD) を使おうとすると、Office365 など WAAD をアイデンティティ基盤として利用するサービスを登録する必要がありましたが、今回まだプレビューですが直接 WAAD のみにサインアップすることが可能になりました。

これまで WAAD を使うのに何度も Office365 の評価版のサインアップをしていたのでこのように単体でサインアップできるようになったのは非常に便利です。

サインアップは以下のURLから実施します。

http://g.microsoftonline.com/0AX00en/5





ようやく Graph API を検証し始めているので、そのうち情報をアップしたいと思います。

[FIM] Active Directory への同期に必要な権限

$
0
0
昨日は .NET ラボさんの勉強会で FIM / AD FS2.0 のハンズオンを実施しました。
回線の混雑具合や時間配分的な問題で用意していたシナリオを終えることは無理があったのですが、いずれリベンジをしたいと思っています。

さて、ハンズオン環境を作る上で一つ入れ忘れていた設定があり参加者の方にご迷惑をかけた点があり、結構忘れがちな設定でもあるのでこの機に書いておこうと思います。


FIM をはじめアイデンティティ管理ツールを使って Active Directory 上のユーザを作成・変更・削除する、というシナリオは企業内ではごく一般的なものだと思います。

その際に、Active Directory 上のオブジェクトをメンテナンスするためのユーザとその権限をどうするのか?というポイントは慎重に検討する必要があります。

実際には Active Directory の管理者とアイデンティティ管理システムの管理者が同じ人や組織なので何も考えずに Domain Admins の権限を持ったユーザや Administrator ユーザそのものをアイデンティティ管理システム上に設定してしまったりしている例も多いと思いますが、出来れば必要最低限の権限を持ったユーザを使いたいところです。

結論から書くと、FIM の場合は以下の2つの権限が必要になります。
・デフォルトネーミングコンテキストに対するディレクトリ・レプリケーションの権限
・管理対象オブジェクトを格納する OU および子オブジェクトに対するフル・コントロール
※デフォルトネーミングコンテキストとは、LDAP 文字列でいうところの DC=xxx,DC=xxx にあたる部分です。

もちろん手動で Active Directory ユーザとコンピュータ から権限を設定することも可能ですが、特にディレクトリ・レプリケーション権限は特殊権限なので設定をするのが面倒です。
そこで通常は DSACLS.EXE を使った以下のようなスクリプト(PowerShell の例)を実行して一気に設定を入れてしまいます。
# Active Directory からネーミングコンテキストを取得
$RootDse = [ADSI] "LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext

# 対象ユーザの SID を取得
$UserPrincipal = New-Object Security.Principal.NTAccount("<NetBOISドメイン名>", "<利用するユーザ名>")
$SID = $UserPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value

# ディレクトリ・レプリケーション権限を付与
DSACLS "$DefaultNamingContext" /G "$($SID):CA;Replicating Directory Changes";

# 対象 OU および子オブジェクトへのフル・コントロール権限を付与
DSACLS "<対象 OU 名>,$DefaultNamingContext" /G "$($SID):GA" /I:T
勉強会でも話をしましたが、 FIM の設定は周辺を含め非常に面倒です。
このようなスクリプトをネタとして持っておいて使いまわす、というのがベストプラクティスなのだと思います。

[WAAD] REST Client で Graph API を直接実行する

$
0
0
# 一部ご指摘をいただきましたので若干修正(Base64 encode ⇒ Base64 url encode)

Windows Azure Active Directory をアプリケーションから利用する際、 Windows プラットフォームであれば、Windows Azure Authentication Library(AAL)を利用することになると思いますが、折角 RESTful な Graph API があるので、汎用 REST Client を使って API へアクセスしてみたいと思います。

■準備
 TenantContextID、AppPrincipalId、SymmetricKey が必要となります。前回同様、CreateServicePrincipal.ps1を使って必要な値を取得します。

 用意が出来たらいよいよアクセスしますが、今回やろうとしていることの全体像を簡単に図にしておきます。

 まず Graph API を利用するために必要な認可を ACS で受け、ACS から取得した Access Token を持って Graph API を利用する、という流れになります。

 実際にやってみると以下のような手順になります。

■Graph API を利用するための Access Token を取得する(REST Client ⇒ ACS)

 初めに、Graph API へのアクセスを行うために必要な Access Token を ACS から取得する必要があります。
 そのためには ACS へ JSON Web Token(JWT)形式でリクエストを投げる必要があります。

 リクエスト先および内容は以下の通りです。

Target Endpointhttps://accounts.accesscontrol.windows.net/tokens/OAuth/2
MethodPOST
Request HeaderContent typeapplication/x-www-form-urlencoded
Request Bodygrant_typehttp://oauth.net/grant_type/jwt/1.0/bearer
assertion
(実際は Symmetric Key でデジタル署名したもの)
{
"alg": "HS256",
"typ": "JWT"
}
{
"aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
"iss": "[AppPrincipalId]@[TenantContextId]",
"nbf": "[UNIX 時間で現在の時刻]",
"exp": "[UNIX 時間でTokenの有効期限]"
}
resourceresource : 00000002-0000-0000-c000-000000000000/directory.windows.net@[テナントID]

 Assertion の部分を作り方は少々面倒ですが、下記の通りです。

 ・ヘッダ部分を Base64 でエンコード

  文字列「{"alg": "HS256","typ": "JWT"}」をこのあたりのツールで Base64 URL エンコードします。

  結果、「eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0」という文字列が得られます。



 ・ボディ部分を作成

  JWT を構成する、nbf(Not Before / 有効開始時刻)、exp(Expiration Time)クレームは UNIX 時刻(1970年からの経過秒数)で表すため、このあたりのツールを使って現在時刻および現在時刻+1時間を変換した値を取得します。

  例えば、2012年9月25日23時00分00秒~2012年9月26日00時00分00秒まで有効なトークンを作成するには、
  "nbf" : "1348581600",
  "exp" : "1348585200"
  というクレームを設定します。

  結果、以下の様な JWT ボディを作成します。
  {
   "aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
   "iss": "[AppPrincipalId]@[TenantContextId]",
            "nbf": "1348581600",
            "exp": "1348585200"
  }

 ・ボディ部分を Base64 でエンコード

  先ほどのヘッダ部分と同様に生成した JWT のボディも Base64 URLエンコードします。

  結果、「eyJleHAiOiIxMzQ4NTU5MTY4IiwiYXVkIjoiM(以下略)」といった文字列が得られます。

 ・ヘッダ+ボディを連結した raw token と SymmetricKey でデジタル署名を生成

  ヘッダ部分とボディ部分を"."(ピリオド)で連結した raw token を作成し、SymmetricKey を Base64 デコードした文字列を使ってデジタル署名を生成します。

  良いオンラインツールがなかったので、以下の Java コードを作成し、署名を生成しました。
  ※Java であることに深い意味はありません。手元に eclipse が起動していた&Java のサンプルがあった、というだけです。
  ※どなたか良いオンラインツールがあれば教えてください。


import javax.crypto.spec.SecretKeySpec;
import javax.crypto.Mac;
import org.apache.commons.codec.binary.Base64;

public class GenerateSignature {

private static byte[] signData(String signingKey, String rawToken) {
SecretKeySpec secretKey = null;
secretKey = new SecretKeySpec(Base64.decodeBase64(signingKey), "HmacSHA256");
Mac mac;
byte[] signedData = null;
try {
mac = Mac.getInstance("HmacSHA256");
mac.init(secretKey);
mac.update(rawToken.getBytes("UTF-8"));
signedData = mac.doFinal();
} catch (Exception e) {
System.out.println("signData error");
}
return signedData;
}
/**
* @param args
*/
public static void main(String[] args) {
String signingkey = "Li7Awy53cq(以下略。SymmetricKey文字列)";
String rawToken = "eyJhbGciOiJ(以下略。ヘッダ部分)).eyJleHAiOiIxMzQ4(以下略。ボディ部分)";
String signature = Base64.encodeBase64String(signData(signingkey,rawToken));
System.out.println(signature);
}

}

 ・Assertion の生成

  生成した署名文字列を先ほどの raw token の後に同じく"."(ピリオド)で連結します。



 このようにして作成した Assertion を他のパラメータと一緒に ACS へ POST します。
 リクエストの POST は Chrome Extension の Advanced Rest Clientを使いました。

 以下の様にパラメータをセットし、[Send request]ボタンをクリックします。


 うまくいくと、HTTP 200 が返ってきて、JSON 形式で Access Token が取得できます。




■取得した Access Token で Graph API を利用する(REST Client ⇒ Graph API)

 いよいよ Graph API を使います。

 リクエスト先および内容は以下の通りです。

Target Endpointhttps://directory.windows.net/[テナントドメイン名].onmicrosoft.com/Users
MethodGET
Request HeaderAuthorization取得した Access Token 文字列(bearer 以降)
x-ms-dirapi-data-contract-version0.8


 先ほどと同様に Advanced Rest Client にパラメータをセットして、[Send request]ボタンをクリックします。


 うまくいくと、HTTP 200 が返ってきて、ユーザ一覧が取得できます。



尚、書き込みを行う場合はロール設定が必要になるので、このあたりは次回以降で。。

OAuth 2.0 が RFC に!!

$
0
0

最後は draft 31 までになり、出る出る詐欺とか言われ続けてきた OAuth 2.0 ですが、Core と Bearer がようやく RFC になりました。

 RFC 6749 - The OAuth 2.0 Authorization Framework
 - http://tools.ietf.org/html/rfc6749

 RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
 - http://tools.ietf.org/html/rfc6750


振り返ると OpenID Foundation Japan で翻訳した約1年前にはまだ draft 22 でしたから1年でかなりリビジョンアップされてきたことになります。

 参考)OpenID Foundation Japan 翻訳・教育 Working Group での翻訳
  OAuth 2.0 core draft 22
  - http://openid-foundation-japan.github.com/draft-ietf-oauth-v2-draft22.ja.html
  OAuth 2.0 Bearer Token
  - http://openid-foundation-japan.github.com/draft-ietf-oauth-v2-bearer-draft11.ja.html


また、途中で Eran Hammer が仕様策定から外れたり、

 OAuth 2.0 and the Road to Hell
 - http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

OAuth 3.0 なんていうことを言い始める人が出てきたり、

 OAuth 3.0: The Sane and Simple Way To Do It
 - http://tav.espians.com/oauth-3.0-the-sane-and-simple-way-to-do-it.html

今はOpenIDなどセキュリティを外付けにすることが多いが、これは危ない。特にツイッターやFacebookは外部アプリが多いので、変なのがまぎれこんでもわからない。セキュリティだけは内部でやってほしい。」なんて言い始める人が出てきたり(違)と、、、紆余曲折がありましたがようやくの RFC 化、ということで各サービスもようやく重い腰を上げる時が来たかな?と思います。

Windows Azure Active Directory も、、、WRAP 0.9 とか draft-13 を使ってる場合じゃないですね。早くちゃんと対応をしてもらえると。。
まぁ、WAAD 自体は JWT なのでまだこれからなところもありますが、 Mike Jones も書いているように今回の RFC 化が関連仕様を加速すると思われるので、ちゃんとしたものになるのもそれほど遠い先ではないのかもしれません。


[FIM2010] XMA/ECMA1.0 から ECMA2.0 へ

$
0
0

MIIS や ILM、無印 FIM 2010 時代からのユーザにとっては対応の検討が必要となる情報です。

これまで独自に管理エージェント(MA)を作成する場合に利用されてきたXMA(Extensible Management Agent)/ECMA1.0(Extensible Connectibity Management Agent 1.0)が今後は使われなくなり、最新のフレームワークである ECMA2.0 のみが使われていくことになりました。

With the release of ECMA 2.0, this feature has been depricated and will be removed in future versions. You should use the Extensible Connectivity 2.0 Management Agent Reference for Connector development going forward.
- http://msdn.microsoft.com/en-us/library/ms698807(v=vs.100).aspx

製品から機能が実際に削除されたりサポートが終了するのは少し先になるとは思われますが、以前のフレームワークで開発をしたモジュールを今のうちに ECMA2.0 に対応させていく計画の立案、および可能な限り早い段階での着手をしておく必要がありそうです。

ちなみに私の作成している FIM 用 GoogleApps 管理エージェントは以前の ECMA1.0 版から ECMA 2.0 版へ作り変えが完了しています。
一緒にソースコードも公開しているので、これから ECMA2.0 を使う人は参考にしてみてください。

 FIM 2010 GoogleApps MA
 - http://fim2010gapps.codeplex.com/

尚、現在バグフィックスおよび機能追加(プロキシ環境での動作、PCNSでのパスワード同期)をしている最中なので、もうすぐ更新版をリリースできると思いますので、ぜひ使ってみてください。

[FIM2010]Google Apps MA 1.1.0 をリリースしました

$
0
0
先日リリースした ECMA2.0 用の Google Apps MA をバージョンアップしました。

ダウンロードURL:
 http://fim2010gapps.codeplex.com/


改修内容は以下の通りです。

  • PCNSを使ったパスワード同期をサポート
  • プロキシサーバ配下の環境での動作をサポート
  • プロキシ認証をサポート
  • 属性の更新が値によって失敗するバグを修正


是非使っていただきフィードバックを!

[告知]オラクルセキュリティフォーラムで登壇します

$
0
0
今回はちょっとお仕事の話を。

この blog では流れ上 Forefront Identity Manager ( FIM ) の話をすることが多いのですが、お仕事では FIM に限らず色々なお客様で色々なベンダのソリューションを扱っていたりします。
また、ロールとしては製品やプロトコルなどの技術はあくまで手段なので、プロジェクト管理やアーキテクチャの検討などが実は仕事の中心だったりします。

その意味で、日本ネットワークセキュリティ協会(JNSA)のアイデンティティ管理WGでやっているようなID管理プロジェクトの進め方のベストプラクティスなんていうのが実際のプロジェクトの中でやっていることの実態です。具体的な進め方やノウハウは以下の本の中で紹介しているので、よろしければどうぞ。

 - クラウド環境におけるアイデンティティ管理ガイドブック


と、少し話がそれましたが、11月26日に大阪、28日に東京で開催されるセミナで私が実際に担当したプロジェクトの事例を紹介することになりました。(東京開催分のサイトはまだ完成していない様なので、できたらまた紹介します)
東京分は諸事情で先送りになりました。年が明けたらやる可能性がありますので、その時はまた告知すると思います。

 - オラクルセキュリティフォーラム in 大阪
  http://www.sbbit.jp/eventinfo/14998?ref=rss
  http://www.oracle.com/goto/jpm121126
  
GSユアサのID管理・シングルサインオン導入事例 

株式会社GSユアサ
情報システム部 活用推進グループ
グループマネージャー
小川 敏宏 氏

伊藤忠テクノソリューションズ株式会社
西日本システム技術部 システム技術第2課
課長
富士榮 尚寛 氏
講演内容 : 導入の背景やOracle Identity Management 製品を使用した実際のシステム化による効果を様々な視点から紹介し、本システムを利用した今後の展開を紹介します。 また、今回導入したシステムの概要や、ID管理・シングルサインオン プロジェクトを円滑に進めていくためのポイントをご紹介します。


プロジェクトでは Oracle Identity Manager 及び Oracle Enterprise Single Sign On を使っているのですが、セミナで話をするのは主にID管理プロジェクトの円滑な遂行方法のノウハウ、という話になると思います。

エンタープライズID管理を検討している企業情報システム部門の方やSIerの方向けですが、お近くの方は宜しければどうぞ。




VS2012 用の Identity and Access Tool が RTM

$
0
0

遅ればせながら 10月23日にリリースされた Visual Studio 2012 用の Windows Identity Foundation Tools を試してみます。

まず、機能面の紹介です。
基本的には以前の WIF の Federation Utility と変わりませんが、個人的には下記が大きなポイントだと思います。

1.Identity Provider を ローカル STS、ビジネス Identity Provider(AD FS2.0)、Windows Azure Access Control Service から選択できるようになった。
  ⇒以前は、新しい STS を作成するか、既存の STS を利用するかの選択だった。

2.管理者として Visual Studio を実行しなくても Identity and Access Tool が利用できるようになった。
  ⇒以前は管理者として Visual Studio を実行しないと Federation Utility が実行できなかった。

3.ACS 側の設定を自動的に作成してくれるようになった。
  ⇒以前は ACS 上に RP の作成およびクレーム・ルールの作成を手動で行う必要があった。

4.認証されていないリクエストに対するアクションを選択できるようになった。
  ⇒以前は単純に STS にリダイレクトするだけだったが、今回から加えて controller を生成することが出来るようになった。


特に3番目、4番目については開発者にとって非常に有用な機能なのではないでしょうか?


では、早速試してみます。

■モジュールのダウンロードとインストール
 モジュールは vsix 形式で提供されていますので、ダウンロード、実行すると Visual Studio の拡張機能が有効になります。

 Identity and Access Tool のダウンロード URL
  http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e


■プロジェクトの作成
 Controller の自動生成を試してみたいので、今回は MVC4 のプロジェクトを作ってみます。もちろん Visual Studio は管理者で実行しなくても大丈夫です。

 テンプレートから web -> ASP.NET MVC 4 Web アプリケーションを選択し、適当な名前を付けてプロジェクトを作成します。


 OK をクリックするとプロジェクト テンプレートの選択画面が出てきますが、デフォルトで選択されている[インターネット アプリケーション]を選んだまま OK をクリックします。



■Identity and Access Tool の設定
 プロジェクトの作成が終わったら、ソリューションエクスプローラからプロジェクト名を右クリックして表示される[Identity and Access]を開きます。


 Choose where your users are from でどの STS を使うのか選択できます。今回は ACS の自動設定を試してみたいので、[Use the Windows Azure Access Control Service]を選択します。
 すると、Select one or more providers from the ones configured in the ACS Namespace: で使用する ACS の Namespace の設定を行うリンクが表示されるので、クリックします。


 Configure ACS namespace のダイアログが表示されるので、ACS namespace および management key を入力します。


 ここで設定する management key は ACS の管理ポータルの管理サービスのパスワードです。



 設定が完了し、ダイアログを閉じると ACS 上に設定されている IdP 一覧が取得されて表示されるので、このアプリケーションで利用したい IdP を選択し、一旦 OK をクリックし Identity and Access Tool を閉じます。


 ちなみに、このとき ACS 管理ポータルを見ると 証明書利用者アプリケーションとして作成したアプリケーションが登録されていることがわかります。


 同様に規則グループも自動生成されます。内容は単なるパススルーなので、必要に応じて編集をしてあげる必要はあります。



■Controller の自動生成
 次は、これまた新機能である Controller の自動生成を試します。
 再び Identity and Access Tool を起動し、今度は[Configuration]タブを開きます。
 すると、Choose how to handle unauthenticated requests という項目があるので、[Generate a controller in your project to handle the authentication experience at the following address]を選択します。


 これで、認証されていないリクエストに対応する Controller が生成されましたので、実際に認証が必要なリクエストを行うように設定を行います。
 今回はデフォルトの About 画面を認証が必要な画面として定義してみます。
 方法は簡単で、HomeController.cs の About() に対して [Authorize] を追加するだけです。



■アプリケーションの実行
 では、F5 キーを押して実際にアプリケーションを実行してみます。

 起動してきたら[バージョン情報]をクリックします。


 すると、ログインページが表示されます。ホームレルム ディスカバリ先として、先ほど ACS から取得してきた IdP 一覧が表示されるのがわかります。


 今回は Google を選択してみます。Google アカウントへリダイレクトされ、Account Chooser が表示されるので、使いたいアカウントをクリックします。



 認証が終わると、ホーム画面へ戻り、ユーザ名が取得できているのがわかります。




いかがだったでしょうか?非常に単純なサンプルだったので実際は色々とカスタマイズが必要にはなるでしょうが、ほぼノンコードでここまで出来るようになっている、という意味で以前のツールに比べてもかなりの進化を遂げていることがわかります。
ACS を使って多くの外部 IdP ユーザを対象にしたアプリケーションを簡単に開発できるので、EC サイトなど B2C シナリオではかなり有用な機能になるのではないかと思います。

Kerberos 認証の設定を確認する

$
0
0

Forefront Identity Manager 2010 (FIM 2010)に限らず Microsoft の製品群は Active Directory を使った Kerberos 認証を多用しています。
こいつです↓(違

図:ケルベロス(笑)

これは、いわゆる「ダブルホップ」と言われる認証の委任を行うことが多いためです。
※もちろん他の理由もありますが。

ダブルホップを知らない方に向けたおさらいですが、Windows ネットワークの世界での認証は一般に NTLM 認証と Kerberos 認証が利用されます。そして、Windows サーバで構成される Web システムといえば、IIS -> SQL Server での2層構造が主流です。
※ブラウザから IIS へアクセスし、IIS が SQL Server へアクセスするという形でホップが2重になっていることからダブルホップと呼ばれます。

この時、NTLM 認証を使っているとクライアントの資格情報を2段階目のホップ(IIS -> SQL Server)へ引き継ぐ(委任)ことが出来ないため、IIS のアプリケーションプールに指定したアカウントを使って SQL Server へアクセスすることになります。アプリケーションプールに指定したユーザアカウントが SQL Server に対して正しくアクセスできる状況であればこの構成でも問題はありませんが、本来はアクセスしてきたユーザの個人アカウントの権限に基づいて SQL Server にアクセスさせたいところです。

図:NTLM 認証フロー

そこで、SharePoint や FIM 2010 をはじめとする Windows で構成された Web システムでは Kerberos 認証を利用します。Kerberos 認証ではユーザの資格情報を委任することが可能となるため、元々のユーザの資格情報を引き継いでバックエンドのサービスへアクセスできます。

図:Kerberos 認証フロー

尚、ダイアグラム内に出てくる SPN(Service Principal Name)については国井さんの blog の以下のエントリを参照してください。
 Service Principal Name (SPN) について
 
と、ここまでは前段なのですが、SPN や Kerberos の設定って往々にして間違えやすいのと間違っていても場合によっては気が付きにくい、という特性があるので、実際のユーザアクセスの中でちゃんと Kerberos 認証が利用できているのか?を確認する必要があります。

そんな時に有用なのが
 Kerberos Authentication Tester
 http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx
です。

簡単に言うと Web リクエストの中で使われた認証方式や Kerberos 認証で使われた SPN などの情報を出力してくれるツールです。

起動して、Url の欄に FIM Portal のアドレスを入れて [Test] をクリックしてみます。
上手く Kerberos 認証を使うように設定できていれば、Authentication type に Kerberos と表示されるはずです。


また、details のリンクをクリックすると更に細かい情報も表示されます。

SharePoint や FIM 2010 を構築した後にとりあえずこのようなツールを使って確認してみると良いと思います。
また、最近は象クラスタの人からも Kerberos が人気なようなので改めて Kerberos 自体のおさらいをしてみるのも良いかも知れません。
Viewing all 771 articles
Browse latest View live