要求とは、ユーザーに関して作成された説明 (名前、ID、キー、グループ、特権、機能など) であり、Active Directory フェデレーション サービス (AD FS) フェデレーションの両方のパートナーによって理解され、アプリケーションでの承認に使用されます。

AD FS フェデレーション サービスには、さまざまな種類のエンティティ間の信頼を仲介する機能があります。フェデレーション サービスを使用すると、任意の値が含まれた要求を、信頼できる方法で交換することが可能になります。リソース パートナーなどの受信側は、これらの要求を使用して承認の判断を行います。

フェデレーション サービスでは、要求は次の 3 つの経路で転送されます。

  • アカウント ストアから、アカウントのフェデレーション サービスを介して、リソース パートナーへ

  • アカウント パートナーから、リソースのフェデレーション サービスを介して、リソース アプリケーションへ

  • アカウント ストアから、フェデレーション サービスを介して、リソース アプリケーションへ

フェデレーション サービスは、これら 3 つのすべての役割で動作するように構成できます。したがって、1 つのフェデレーション サービスで 3 つすべての通信フローを簡易化できます。

フェデレーション サービスでは、ID 要求、グループの要求、およびカスタム要求という 3 種類の要求がサポートされています。次の表では、これらの各種の要求について詳しく説明します。

要求の種類 説明

ID

AD FS では、UPN、電子メール、および共通名は ID 要求と呼ばれます。

  • UPN: Kerberos スタイルのユーザー プリンシパル名 (UPN) を示します (例: user@realm)。1 つの要求のみを UPN の種類にできます。複数の UPN 値を通信する必要がある場合でも、UPN の種類にできるのは 1 つのみです。その他の UPN は、カスタム要求の種類として構成できます。

  • 電子メール: Request for Comments (RFC) 2822 スタイルの電子メール名を示します (例: user@domain)。1 つの要求のみを電子メールの種類にできます。複数の電子メール値を通信する必要がある場合でも、電子メールの種類にできるのは 1 つのみです。その他の電子メールは、カスタム要求の種類として構成できます。

  • 共通名: 個人設定用に使用される任意の文字列を示します。たとえば、"John Smith" や "Tailspin Toys の従業員" などです。1 つの要求のみが、共通名の種類を保持できます。共通名要求の一意性を保証するためのメカニズムはありません。このため、承認の判断でこの要求の種類を使用する場合は注意が必要です。

グループ

グループまたは役割内のメンバーシップを示します。管理者は、"グループの要求" というグループの種類が割り当てられた個別の要求を定義します。たとえば、[Developer, Tester, Program Manager] というグループの要求のセットを定義します。個々のグループの要求は、要求の生成やマッピングを行うための個別の管理単位となります。グループの要求の値は、メンバーシップを示すブール値として考えるとわかりやすくなります。

カスタム

ユーザーに関するカスタム情報 (従業員 ID 番号など) が含まれた要求を示します。

1 つのトークンに、3 種類の ID 要求のうちの複数が含まれている場合、それらの ID 要求の優先順位は次のとおりです。

  1. UPN

  2. 電子メール

  3. 共通名

トークンが発行されるためには、これらの ID 要求のうち少なくとも 1 種類が含まれている必要があります。

要求のマッピング

Active Directory フェデレーション サービス (AD FS) は、WS-Federation のパッシブな要求側プロファイル (WS-F PRP) を使用します。WS-F PRP は、フェデレーション サービスによって発行されたセキュリティ トークンによって要求を伝えます。これらの要求は最初に、Active Directory ドメイン サービス (AD DS) アカウント ストア、または Active Directory ライトウェイト ディレクトリ サービス (AD LDS) アカウント ストアのいずれかのアカウント ストアから生成されます。

フェデレーション サービスでは、要求がフェデレーション パートナーとの間でやり取りされるときに、それらの要求をマッピングできます。要求のマッピングとは、要求をマッピングしたり、削除またはフィルター処理したり、あるいは入力方向の要求を出力方向の要求に渡したりする機能です。要求のマッピングは、フェデレーション パートナーごとに変えることができます。これらの要求の生成およびマッピングの定義は、フェデレーションの構成にとって重要です。要求のマッピングでは、大文字と小文字を区別する文字列比較が使用されます。次の図は、要求のマッピング プロセスを示しています。

要求マッピング プロセス

組織要求のセット

入力方向の要求はすべて、組織の要求にマッピングされます。組織の要求とは、組織の名前空間内にある、中間形式または標準化された形式での要求です。内部のフェデレーション サービス操作はすべて、組織の要求のセット上で実行されます。組織の要求は、リソース アプリケーションによって使用されます。

組織の要求では、通信を行う必要のある 2 つの組織間でマッピングを個別に管理する必要はありません。各組織は、組織の要求に対する (または組織の要求から発する) 単一のマッピングを定義します。これによって、AD FS の管理上の複雑さを軽減できます。たとえば、フェデレーションに、次の数のアカウント パートナーとリソース アプリケーションが存在すると仮定します。

x 個のアカウント パートナー

y 個のリソース アプリケーション

この場合、フェデレーションには、x + y 個の要求のマッピングがあります。

これは、考えられる要求のマッピング数である x × y 個より少なくなっています。具体的な例として、フェデレーション サービスに、次の数のアカウント パートナーとリソース アプリケーションが存在するとします。

3 個のアカウント パートナー

7 個のリソース アプリケーション

入力方向の要求から出力方向の要求に直接マッピングが行われた場合、フェデレーションが必要とする要求のマッピング数は、21 個ではなく、10 個だけです。

電子メール

電子メール要求の種類は常に、電子メール要求の種類にマップされます。このマッピングの一部として、アカウントのフェデレーション サービス上でドメイン サフィックスが定数値にマップされる場合があります。ドメイン サフィックスが定数値にマップされることで、パートナー組織が自身の内部フォレスト構造に関する情報を誤って別の組織に提供してしまうことを防いでいます。リソースのフェデレーション サービスでは、ドメイン サフィックスが、定数値の一覧を条件としてフィルターされる場合があります。

次の例は、Tailspin Toys と Adventure Works という 2 つの組織間の AD FS フェデレーションについて説明しています。この例では、Tailspin Toys がアカウント パートナーで、Adventure Works がリソース パートナーです。

  • アカウントのフェデレーション サービスとしての役割を果たす Tailspin Toys は、電子メールの組織の要求を Adventure Works の出力方向の電子メール要求にマップします。このマッピングの一部として、すべての電子メールのサフィックスを tailspintoys.com にマップします。組織の電子メール要求が (e-mail=jsmith@sales.tailspintoys.com) であるとすると、出力方向の電子メール要求は (e-mail=jsmith@tailspintoys.com) になります。

  • リソースのフェデレーション サービスとしての役割を果たす Adventure Works は、入力方向の Tailspin Toys の電子メール要求を電子メールの組織の要求にマップし、このマッピングの一部として、tailspintoys.com を条件としてサフィックスの一覧をフィルターします。このため、入力方向の Tailspin Toys の電子メール要求 (email=jsmith@tailspintoys.com) は受け入れられますが、入力方向の Tailspin Toys の電子メール要求 (e-mail=jsmith@adventure-works.com) は拒否されます。

UPN

UPN 要求の種類は常に、UPN 要求の種類にマッピングされます。これらの要求には、電子メール要求と同じ方法でサフィックスのマッピングとフィルター処理が行われます。ただし、AD DS では @ 記号のない UPN が許可されるため、UPN サフィックスのマッピングが定義されている場合、アカウントのフェデレーション サービスによってサフィックスの前に @ 記号が付けられます。UPN サフィックスのマッピングが定義されていない場合は、サフィックスが渡されると、フェデレーション サービスによって @ 記号のない UPN がそのまま渡されます。リソース側で、どのような UPN サフィックスも許可されている場合、@ 記号のない UPN は受け入れられます。特定の UPN サフィックスのみが許可されている場合は、@ 記号のない UPN は拒否されます。

共通名

共通名要求の種類は常に、共通名要求の種類にマッピングされます。追加の規則はありません。

カスタム

カスタムの要求の種類は常に、別のカスタムの要求の種類にマッピングされます。たとえば、入力方向の要求のセットが (UPN, Custom=[EmployeeNumber, TaxPayerID]) であり、組織の要求のセットが (UPN, Custom=[Employee, SSN]) である場合、EmployeeNumber から Employee へ、および TaxPayerID から SSN へマッピングを作成できます。

グループ

グループの要求の種類は常に、別のグループの要求の種類にマッピングされます。たとえば、入力方向の要求のセットが (UPN, Group=[One, Two, Three]) であり、組織の要求のセットが (UPN, Group=[X,Y,Z]) である場合、One から Y、Two から X、および Three から Z にマッピングを作成できます。

グループと UPN 間のマッピング

前のセクションで説明した標準のマッピングに加え、グループと UPN 間という特殊な要求のマッピングを使用することもできます。グループと UPN 間の要求のマッピングは、要求がアカウント パートナーからの入力方向のものである場合に、リソースのフェデレーション サービスでのみサポートされます。この場合、UPN 要求の種類は UPN 要求の種類にマッピングされません。代わりに、グループと UPN 間の要求のマッピングを示した、順序付き一覧を提供します。

たとえば、グループと UPN 間の一覧は次のようなものになります。

  1. Dev to developers@internal.tailspintoys.com

  2. Test to testers@internal.tailspintoys.com

  3. PM to progmgrs@internal.tailspintoys.com

入力方向の要求のセットが (Common name=John Smith, Group=[Dev]) である場合、組織の要求のセットには (Common name=John Smith, UPN=developers@internal.tailspintoys.com) が含まれます。一覧には順序が付いていることに注意してください。このため、要求セット (Common name=John Smith, Group=[Dev,PM]) は、(Common name=John Smith, UPN=developers@internal.tailspintoys.com) となります。また、入力方向の要求に UPN があれば、UPN は上書きされます。この特殊なマッピング規則は、具体的にはレガシ リソースにアクセスするグループ ベースのリソース アカウントをサポートします。グループと UPN 間のマッピングの順序は、フェデレーション サービスの信頼ポリシーで指定されます。

要求の監査

一部のグループの要求およびカスタム要求は、監査可能として指定できます。監査を有効にすると、監査によって要求の名前がセキュリティ イベント ログで公開されますが、要求の値は省略されます。監査可能な要求の例としては、保険証番号があります。"保険証番号" という要求名は公開されますが、この要求に格納されている実際の番号の値は公開されません。要求の値は、要求が生成またはマップされたときに監査されません。

ID 要求は常に監査可能です。

関連項目


目次