[ACSv2]OpenID Providerを登録する

先日のVittorioのblogでACSv2のIdentity ProviderとしてOpenIDが登録できるようになった、という話がありましたので早速試してみました。

「OpenID now appears among the possible identity providers (it is not in the portal, but an OpenID issuer can be set up via management service) 」

と言っても彼のblogにもある様に、ポータルには出てこないのでmanagement service経由で登録をする必要があります。（要コーディング）

参考になる情報は、以下にあります。
・Alik Levin氏のblog
　http://blogs.msdn.com/b/alikl/archive/2011/02/08/windows-azure-appfabric-access-control-service-acs-v2-programmatically-adding-openid-as-an-identity-provider-using-management-service.aspx
・CodePlexで公開されているサンプル
　http://acs.codeplex.com/wikipage?title=Management%20Service


と言っても毎回OpenID Providerのアドレスなどをコードに埋め込んでリコンパイル、、となると面倒なのでGUIクライアントを作ってみました。
※sourceforge.netにパッケージごとおいてありますので、自己責任でどうぞ。
　https://sourceforge.net/projects/acsv2management/files/


使い方ですが、まずはAppFabric Lab（https://xxx.accesscontrol.appfabriclabs.com/）より設定に必要な以下の情報を取得しておきます。

１．ネームスペース名
　これは言わずもがなhttps://xxx.accesscontrol.appfabriclabs.com/のxxxの部分です。
２．Management Serviceの管理アカウント名
　ポータルの左のメニューからManagement Serviceを開くと確認できます。

３．管理アカウントのパスワード
　上のアカウント名をクリックするとCredentialsという項があるのでそこでPasswordをクリックすると出てきます。

後は設定するOpenID Providerのサインインアドレスを調べておきます。
例えばYahoo! Japanであれば「https://open.login.yahooapis.jp/openid/op/auth」となります。

早速作成したGUIを立ち上げて準備した情報を設定します。

そして[Go !]をクリックして以下のダイアログが出れば成功です。

この状態で管理ポータルのIdentity Providersを見ると先ほど設定したOpenID Providerが出てきているはずです。

ただ、この状態だとClaimのルールが設定されていないので、左メニューのRule groupsからOpenIDを使いたいRelying Party用のルールを選んでルールを追加・保存してください。


後は設定したRPにアクセスしてみてACSのサインインページで設定したIdPを選択すると見事設定したOpenID Providerの認証ページにリダイレクトされ、認証・属性読み取りへの同意をするとRPが表示できるはずです。

ACSのサインイン

Yahooへリダイレクト

属性読み取りへの同意

RPへ

プロトコルとトークン形式

先週金曜日（3/11）にMS安納さんと「AppFabric ACS V2 で構築するSSO」セミナをやったのですが、その時にお話しした内容を少々。
（事情があり資料は公開しません）

私のセッションでは
・アイデンティティにまつわる言葉の定義
・プロトコルとフォーマット（トークン形式）
・各種情報へのポインタ
についてお話をしました。

その中で一番混乱しやすい「プロトコルとフォーマット」の話を軽く触れておきたいと思います。（現にMSDNフォーラムや先日のMVP Global Summitでもみなさんが一番わかりにくい、と話をしていましたし）
また、セッション内で本当は見せようと思っていたデモを公開します。

セッション内では以下の様に説明をしました。

プロトコル	アイデンティティ情報を受け渡す方法
トークン	アイデンティティ情報を表現する方法

例えば
・プロトコル
　ws-federation、SAMLなど
・トークン
　SAML、SWT、JWTなど
です。

実は上記の例の中のSAMLがこのプロトコルとトークンを混乱させる一番の原因になっているのでは？と思っています。SAMLはプロトコルであり、トークン形式でもあるためです。
例えばws-federationプロトコルはSAMLトークンを使うことも可能ですし、もちろんSAMLプロトコルはSAMLトークンを利用します。
※そういう意味でプロトコルのSAMLをトークンのSAMLと区別するためにSAMLPと呼んだりします。


では、それぞれの例を見ていきます。

まずはプロトコルですが、以下がSAMLプロトコルの流れの例です。（SAMLのやり取りはプロファイルという形で他にもやり取りの方法が規定されています。またこのやり取りはws-federationでも同じ流れです）










実際には各フローのそれぞれのメッセージの形式がプロトコルとして規定されています。


次にトークンです。こちらもSAMLトークンの例を示します。

















こんな感じで発行元、署名、属性情報がXML形式で入っています。



Azure上にACSv2と連携する簡単なデモを作成しているのでこちらを触ってもらえば実際の動きと発行されたトークンを見ることができます。

１．以下のURLにアクセス
　　http://stvc-demo.cloudapp.net/default.aspx

２．ACSv2のサインイン画面にたどり着くので好きな認証元（IdP）をクリック




















３．例えばFacebookをクリックするとFacebookの認証画面へリダイレクトされるのでログイン
















４．無事にログインするとアプリケーションに戻り、ポストされたトークンが表示される（以前紹介したSecurity Token Visualizer Controlを利用）

















#Azureの特別導入プランのXSインスタンスを使っているのでしばらくは公開しておきますが、ACS側の仕様の変更などもあると思いますのでそのうち消します。。。

Windows Azure AppFabric ACSv2 でのホームレルムディスカバリ問題対策

マルチテナント環境でフェデレーションを行うときに必ず問題になるのが「ホームレルムディスカバリ」対策です。

「ホームレルムディスカバリ（Home Realm Discovery）問題」とは簡単に言うと、複数の組織が共通のアプリケーションを使う際に、アプリケーション側はどのIdP（レルム）で認証されるべきなのか？（どのIdPにリダイレクトすべきなのか）を判断できない、という問題です。

この問題に対してAD FS2.0ではユーザ自身にどのIdP（レルム）で認証されるのかを選択させる方式をとっていました。

この方式は各大学機関がIdPとなる学術認証ネットワークでの Shibboleth の実装でも採用されていますが、大きく2つの問題があると考えられます。

１．IdPの数が増えてきたときに選択するのが大変
　どのIdPを選択したかはCookieに保存されるので、2度目のアクセスからはIdPを選択することはないのですが、数が増えると間違える可能性もありますし、何より自分のIdPを探し出すのが大変です。間違えたIdPを選択してしまうとブラウザのCookieをクリアしないといけない、という点においても運用上大きな問題です。

２．他のIdPの名前が見えてしまう
　IdPを選択させる＝他のIdPも見えてしまう、ということになります。例えば競合企業がそのサービスを使っているのかどうか、などが見えてしまうというのは一般的な企業のポリシー上許されない可能性が高いと言えます。

■Windows Azure AppFabric ACSv2におけるホームレルムディスカバリ
さて、ここで本題です。
これまでACSv2（現在ラボ公開）ではAD FS2.0での実装と同様に登録したIdPをすべてサインイン画面に羅列する、という方式でホームレルムディスカバリ問題へ対応してきました。

しかし、最近の更新でIdPにAD FS2.0を使う場合に限ってですがこの問題への対策が実装されました。（一部課題はありますがその点は後述します）

具体的にはサインイン画面でメールアドレス形式でのログインを行い、ドメインパート（@の右側）を見てどのIdPへリダイレクトするかを決める、という方式です。

ACSv2にAD FS2.0のIdPを登録する際に「Email domain names」という設定項目が新しくできており、そこに設定されたドメイン名とユーザが入力したメールアドレスのドメイン名をマッチングして適切なIdPへリダイレクトする、というものです。

以下が設定画面です。ここでは「myidp.local」というドメインを指定しています。

サインイン画面で「xxx@myidp.local」というログイン名でログインすると適切なIdPへリダイレクトされます。

もちろん違うドメイン名のアドレスでログインすると別のIdPへリダイレクトされます。

■今後の課題
先ほど一部課題がある、と述べましたが具体的には
「ACSv2のサインイン画面で入力したログイン名がリダイレクトされた先のAD FS2.0のログイン画面に引き継がれない」
という問題があります。

どういうことかというと、

・AD FS2.0のサインインにフォーム認証を使っている場合は、リダイレクトされた後に再度ユーザ名を入力する必要がある
・AD FS2.0のサインインにWindows統合認証を使っている場合は、ACSv2にどんなユーザ名を入れてもPCにログインしているユーザでログインされる

ということになります。Windows統合認証を使ってい場合はある意味仕方がないとは思いますが、せめてフォーム認証の場合はユーザ名を引き継ぐことが出来れば、、と思いますので、今後の改善が望まれます。
（と言っても初回のみなのでそれほど重要ではないかも知れませんが）

blog feedを更新しました

ずっと手を付けようと思っていて放置していたマイブログリスト（ナビゲーションの左下）を更新しました。

カテゴリとしては、とりあえず

・Identity関連　：　特に製品に関係なくアイデンティティ関連の情報を発信しているblog

・FIM/ILM関連　：　その名の通り、FIMやILM関連の情報を発信しているblog

・AD FS/WIF/ACS関連　：　同じくAD FSやWIF、AppFabric ACS関連の情報を発信しているblog

を用意しました。

日々僕が巡回しているリスト、と思ってもらえればよいかと思います。

最近はめっきりAD FS2.0やFIMなどの割と特定の製品に関するエントリばかりになってしまっていますが、元々は中々日本語でのアイデンティティ管理関連の情報ソースが少ないので、うまく情報を集約できるようなサイトを目指していたので、今後は少しでもその方向にいければなぁ、、と思いつつリソースとパワーが足りない日々だったりします。

（イメージはSalesforce.comに行ってしまった元SunのPat PattersonさんがやっているPlanet Identityみたいな感じ）

AppFabric ACSののセミナに登壇予定

少し先（3/11）になりますが以下のセミナでしゃべります。
登録ページにはまだタイトル未定となっていますが、本当に未定ですｗｗ

Windows Azure AppFabric ACS で構築するシングルサインオンシステム
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032477539&Culture=ja-JP


内容的には安納さんのblogにも紹介されているようにアイデンティティにまつわる用語や標準の整理をさせていただく予定。

もちろん安納さんのパートも必聴です。AppFabric関連の話ってService Busにフォーカスがあたりがちなので、なかなかAccess Control Serviceに絞った話は聴けません。TechEdでもこんなにマニアックなセッションはなかったと思います。


資料は全く未着手なので、そろそろ作り始めようかと。。来週はまるまるシアトルなので。

クレームの発行状態を確認する

AD FS2.0やAppFabric ACSを使った外部認証を有効にしたアプリケーションを開発しているとちゃんとセキュリティトークンが発行されているのか、トークンの中のクレームに何が入っているのかの確認をしたくなります。
もちろんfiddlerを使って実際のHTTPのやり取りの中からPOSTされるSAMLトークンをキャプチャしてSAML 2.0 Debuggerでデコードする、というのもやり方としてはありなのですが、いかんせん生のXMLを見ていく必要がありますし何より手順として少々面倒です。

ということで、私が使っているのがSecurity Token Visualizer Control（STVC）です。PDC等のカンファレンスでVittorioさんが使っているのを見たことがある方もいらっしゃると思いますが、彼がcodeplexに公開しているSAML2.0のトークンを解析して表示してくれるコントロールです。

公開URL：
http://archive.msdn.microsoft.com/TokenVisualizerCtrl

最新版：
SecurityTokenVisualizerControl PDC09 WIF RTM


■環境の構築
※WIF SDKやVisual Studio、IISのアプリケーションプールの設定が正しくされている前提です。

・アーカイブを展開する
では、さっそく使ってみましょう。上記URLからダウンロードしたファイルを実行するとアーカイブの展開および環境のチェック、デプロイが行われるのですが最新版がPDC09とあるように少々古い環境なので最近の環境ではそのままでは使えず、セットアップ過程におけるDependency Checkerでこけてしまいます。これは前提となる環境がVisual Studio 2008だったりするせいなので、アーカイブの展開が終わったらさっさとキャンセルボタンを押してセットアップは省略してしまいましょう。
すると、展開先のフォルダ以下にアーカイブが展開され、「code\Microsoft.Samples.DPE.Identity.Controls\bin\Debug」以下にSecurityTokenVisualizerControl.dllが出来ています。
もちろん同梱されているプロジェクトをVisual Studio 2010でビルドしなおしてdllを再作成してもOKですが、面倒なのでこのdllをそのまま使ってしまいます。

・作成するプロジェクト内でSTVCを利用する
この辺りはVisual Studioを使い慣れている方には当たり前なのでしょうが、上記で解凍したコントロール（dll）をプロジェクトで使えるようにするためにコントロールを参照する必要があります。

ツールボックスを表示して、コントロールの参照から解凍したdllを参照します。
すると、ツールボックス内にSTVCのアイコンが出てきますので、プロジェクトのWebページ上にドラッグ＆ドロップします。これでコントロールの配置は完了です。

・Federation Utilityを実行しSTSへの参照設定を行う
ここはAD FS2.0やACSを使った外部認証を有効にする手順と同じですが、Federation Utilityを使ってSTS参照を有効にします。今回はACSを参照することにします。
※もちろんACS側へのRelying Partyの設定も必要です。

・ちょこっとweb.configを修正する
実はFederation Utilityを実行してもweb.configに手動で設定を行う必要があります。（.NET Framework 4.0を使う場合のみ？）結構はまりポイントなので、うまく動かない場合は一度このあたりの設定を疑ってみる必要があるかもしれません。

<system.web>以下
　<httpRuntime requestValidationMode ="2.0"/>

<microsoft.identityModel>以下
　<service saveBootstrapTokens="true">


これで準備は完了です。

■使ってみる
では、作成したプロジェクトを発行してWebページにアクセスしてみます。

まずはACSで認証されます。

うまくトークンとクレームが発行されていれば、Webページのコントロールをクリックして展開されるテーブルにトークンの情報が表示されるはずです。

上の方に発行されたクレームの型と値、発行元の情報が、下の方に実際に発行されたSAMLトークンの情報が表示されているのがわかります。


アプリケーションのデバッグはもちろん、AD FS2.0やACSなどの基盤が正しく動作していることの確認を行うためにも使えそうです。（もちろんデモ用途にも）

[FIM2010]一般ユーザ権限でセキュリティグループを管理する

FIM2010の大きな特徴でもあるグループ管理機能も実はデフォルトでは殆ど無効化されているので色々と手を加えてやる必要があります。

以下が一般ユーザでFIMポータルにログインした際の初期画面です。

見ての通り、配布グループについては表示されていますが、セキュリティグループについては表示すらされていません。（実は配布グループについても画面表示はされていても実際に作成をしようとするとアクセスが拒否されてしまうので、そのままでは使えません）

この状態から一般ユーザが自身でセキュリティグループの管理ができる状態にするためには以下のステップを踏む必要があります。
・画面に操作メニューを表示する
・セキュリティグループを管理する権限を付与する

それぞれを解説していきます。

■画面に操作メニューを表示する
まず、画面のカスタマイズです。

FIMポータルの画面の中のユーザメニューに関連する部分は
・ナビゲーションバー
・ホームページ
で構成されています。

それぞれに何を表示するか、についてはAdministratorでログインした場合にポータルの右側に表示される管理メニューより対応するリソースのカスタマイズを行います。

では、どうすればホームページやナビゲーションバーに各機能が表示されるか？ですが、これは少しわかりにくいのですが、各リソースの「使用法キーワード」に「BasicUI」という文字列を入れることで表示されます。

ナビゲーションバーリソース

ホームページリソース

ここまで設定をすると一般ユーザのポータルにもメニューが表示されます。（すぐに画面に反映させたい場合はiisreset等でIISを再起動してください）

次は表示されたメニューを実際に使えるようにします。

■セキュリティグループを管理する権限を付与する
先の配布グループの件もそうなのですが、一般ユーザがセキュリティグループを管理できないのは以下の2点が原因です。
・関連する管理ポリシー規則（MPR）がデフォルトでは無効化されている
・関連する管理ポリシー規則の申請元として定義（許可）されているのがAdministratorsのみである

それぞれを解消して行きます。

まず、管理ポリシー規則の有効化です。
対象となる管理ポリシー規則は「Security Group xxxx」という表示名のものです。検索ウィンドウに「Security」と入れて検索すると対象のもののみが表示できるので便利です。
それぞれの管理ポリシールールを開いて[無効化]のチェックを外して保存すればOKです。

次に、管理ポリシー規則を利用するための権限の付与です。
デフォルト状態を見てみるとセキュリティグループ管理を行うための管理ポリシー規則の申請元として定義されているのは「Security Group Users」というセットです。
このセットの定義をみるとメンバとなっているのはAdministratorsに属するユーザのみとなっているので、ここに一般ユーザも追加することで権限を与えることが可能です。

さて、それなりに長い道のりでしたがここまで設定を行ってようやく一般ユーザでもセキュリティグループを管理することができるようになりました。
（もちろんFIMで作ったセキュリティグループをActive Directoryへ反映させるには別途管理エージェントの設定や同期規則の設定が必要です）