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