シリーズで、2台のADFSサーバーを利用して、ADFSサーバー間でクレームの受け渡しをするための設定についてお話をしています。今回はADFSサーバー間でのクレームの受け渡しについて紹介します。
1台のADFSサーバーの中でトークンを生成する場合、以下のステップを経てトークンの中に入るクレームが決定します。
1．受け付け変換規則
2．発行承認規則
3．発行変換規則
1．については要求プロバイダー信頼、2．と3．については証明書利用者信頼でそれぞれ設定できると以前の投稿でもご紹介しました。
続いて2台のADFSサーバーでトークンを生成する場合ですが、このときは1～3のステップを2回繰り返すイメージになります。
■ ■ ■
ところで、2台のADFSサーバーでトークンを生成し、トークン内に登録するクレームを決定する場合、注意しなければならないポイントがあります。続いて、それについて確認します。
RP 側の受け付け承認規則では、CP側でのクレームをパススルーする
単一組織における受け付け承認規則では、LDAP から属性値を取得する処理を設定しておくことが一般的な処理でしたが、組織間(ADFSサーバー間)での構成になると、LDAP からの属性値の取得は既に CP 側で行われています。そのため、RP 側の受け付け承認規則では、CP 側から送られてきたクレームをパススルーするのが一般的な処理になります。ただし、異なる組織から送られてきたクレームには不適切な属性値が含まれている場合も考えられるので、すべてをパススルーするのではなく、特定の属性値を持つクレームだけをパススルーするように構成することが望ましいです。(たとえば、RPの受け付け変換規則で、CPの発行変換規則から受け渡されたメールアドレスのうち、サフィックスが@example.comとなっているアドレスだけをRP内で処理するようにすれば、不適切なアドレスを持つクレームがCP→RP間で受け渡しされることもなくなるでしょう)
RP 側のクレームの名前は必要に応じて CP 側で変更する
組織が異なると、企業文化などの違いから同じ情報でも、異なる属性名として扱われる場合があります。例えば、メールアドレスが含まれるクレームでも、組織Aではクレーム名を「mailaddress」と呼び、組織Bでは「UPN」と呼ぶ場合があります。このように同じ情報でも異なるクレーム名で扱われている場合、RP側の受け付け承認規則ではクレーム名そのものを変換するようなシングル サインオンを作成する必要があります。例えば、上の図のようにRP側では発行承認規則でUPNの値をもとに認可を行うように設定していたとします。しかし、CP側からUPNの情報をUPNではなく、mailaddressとして送られて来たらRP側で認可を行うことができないため、RP側の受け付け承認規則でmailaddressのクレームをUPNのクレームとして扱うように変換しなければなりません。
以上です。
2つのADFSサーバーが異なる会社組織で運用されている場合、どのようなクレームが受け渡しされるかは事前に会社間で詰めておくことが重要なポイントとなります。
次回は、2台のADFSサーバーを構成すると、ユーザーがサインインする際の画面も変わりますので、そのあたりについて解説します。
