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