要求のパススルーとフィルターを使用するタイミングの規則
特定の入力方向要求の種類を取得する必要があるときに、Active Directory Federation Services (AD FS) でこの規則を使用して、その後、アクションを適用できます。このアクションによって、入力方向の要求の値に基づいて発生する出力が決まります。 この規則を使用する場合、次の表の規則ロジックと一致する要求を、規則で構成するオプションに基づいてパススルーまたはフィルター処理します。
| 規則のオプション | 規則のロジック |
|---|---|
| すべての要求値をパススルーする | 入力方向の要求の種類が "指定した要求の種類" に等しく、値が "すべての値" に等しい場合、要求をパススルーします |
| 特定の要求値のみをパススルーする | 入力方向の要求の種類が "指定した要求の種類" に等しく、値が "指定した要求値" に等しい場合、要求をパススルーします |
| 特定の電子メール サフィックスの値に一致する要求値のみをパススルーする | 入力方向の要求の種類が "指定した要求の種類" に等しく、値が "指定したサフィックス値" に等しい場合、要求をパススルーします |
| 特定の値で始まる要求値のみをパススルーする | 入力方向の要求の種類が "指定した要求の種類" に等しく、値が "指定した要求値" で始まる場合、要求をパススルーします |
次のセクションでは、要求規則の概要と、その規則を使用するタイミングについて詳しく説明します。
要求規則について
要求規則は、入力方向の要求を受け取り、条件 (x の場合に y を実行) を適用して、条件のパラメーターに基づいて出力方向の要求を生成するビジネス ロジックのインスタンスを表します。 次の一覧に、このトピックを読む前に理解しておく必要のある、要求規則に関する重要なヒントを示します。
AD FS 管理スナップインで要求規則を作成するには、要求規則テンプレートを使用する必要があります。
要求規則は、要求プロバイダー (Active Directory、別のフェデレーション サービスなど) から直接、または要求プロバイダー信頼の受付変換規則の出力から、入力方向の要求を処理します。
要求規則は、要求発行エンジンによって、特定の規則セット内で時系列に従って処理されます。 規則に優先順位を設定すると、特定の規則セット内の先行する規則で生成された要求をさらに調整またはフィルター処理できます。
要求規則テンプレートでは、常に入力方向の要求の種類を指定する必要があります。 ただし、1 つの規則を使用して、要求の種類が同じ複数の要求の値を処理できます。
要求規則および要求規則セットの詳細については、「要求規則の役割」をご覧ください。 規則を処理する方法の詳細については、「要求エンジンの役割」をご覧ください。 要求規則セットを処理する方法の詳細については、「要求パイプラインの役割」をご覧ください。
すべての要求値をパススルーする
この操作を使用する場合、指定した要求の種類の入力方向の要求値すべてが、出力方向の要求としてパススルーされます。 たとえば、入力方向の要求の種類が "役割" として指定されている場合は、すべての入力方向の要求値が、新しい出力方向の要求に個別にコピーされ、出力方向の要求の種類は "役割" になります。
要求のフィルター処理
AD FS では、要求フィルターとは、特定の値のみが出力方向の要求としてパススルーまたは送信されるように、入力方向の要求値をフィルター処理または制限することです。 これを実現するのが、入力方向の要求のパススルーまたはフィルター処理規則です。 この規則のプロパティ内で、指定した条件を満たす値のみがパススルーするように、入力方向の値をフィルター処理する条件を設定できます。
たとえば、この規則を使用すると、入力方向の要求の種類が "役割" と一致するとき、またはユーザー名に関する要求のみを発行する必要があるときに、購入者の要求値に一致する要求のみをパススルーできますが、ユーザーの社会保障番号を含む要求はパススルーできません。
この規則でフィルター条件を使用すると、入力方向のすべての要求で、どの要求が規則で設定された条件に一致するかが確認されます。 その他の要求はすべて無視され、指定した要求値の中で、選択した要求の種類に一致するものだけがパススルーします。
たとえば、次の図に示すように、要求の種類が UPN と一致し、末尾が @fabrikam.com の入力方向の要求のみをフィルター処理するという条件で規則が設定されている場合、この条件を満たしていない入力方向の要求はすべて無視されます。 末尾が @fabrikam.com でも、要求の種類が "電子メール アドレス" の場合、その入力方向の要求は無視されます。 この場合は、Nick@fabrikam.com という値を含む要求のみが、証明書利用者に送信されます。
要求プロバイダー信頼でのこの規則の構成
要求プロバイダー信頼を使用する場合、この規則は、特定の制約に一致する要求プロバイダーからの入力方向の要求のみをパススルーするように構成できます。 たとえば、要求プロバイダーからの電子メール要求のみを受け入れるとします。この場合は、この規則テンプレートを使用して、末尾が要求プロバイダーのドメイン ネーム システム (DNS) 名で、種類が電子メールの要求を受け入れます。
証明書利用者の信頼でのこの規則の構成
証明書利用者の信頼を使用すると、この規則は、証明書利用者に送信される出力方向の要求をパススルーまたはフィルター処理するように構成できます。 要求の種類すべてを、すべての証明書利用者が認識できるとは限りません。また、要求によっては、特定の証明書利用者に送信しないようにする必要がある機密情報が含まれる場合もあります。 この規則テンプレートは、特定の証明書利用者の信頼に対して、こうしたポリシーを適用するのに役立ちます。
この規則の作成方法
この規則は、要求規則言語を使用するか、AD FS 管理スナップインで入力方向の要求のパススルーまたはフィルター処理規則テンプレートを使用して作成します。 この規則テンプレートには、次の構成オプションがあります。
要求規則名を指定する
入力方向の要求の種類を指定する
すべての要求値をパススルーする
特定の要求値のみをパススルーする
特定の電子メール サフィックスの値に一致する要求値のみをパススルーする
特定の値で始まる要求値のみをパススルーする
このテンプレートの作成方法については、AD FS 展開ガイドの「入力方向の要求をパススルーまたはフィルター処理する規則を作成する」を参照してください。
要求規則言語の使用
要求値がカスタム パターンに一致する場合にのみ要求を送信する場合は、カスタム規則を使用する必要があります。 詳細については、カスタム規則を使用するタイミングに関するトピックを参照してください。
パススルーとフィルター処理規則の構文の作成例
シンプルなフィルター処理規則では、上記で説明したプロパティのいずれかに基づいて要求をフィルター処理します。 たとえば、次の規則は、すべての電子メールの要求をパススルーします。
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(claim = c);
フィルターは論理的に AND で連結できます。 たとえば、次の規則は、値 johndoe@fabrikam.com を持つすべての電子メール要求を受け入れます。
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", value == "johndoe@fabrikam.com "] => issue(claim = c);
前の例では、フィルターには常に等価演算子が使用されています。 要求規則言語でサポートされる演算子を次に示します。
== - 等しい (大文字と小文字が区別されます)
!= - 等しくない (大文字と小文字が区別されます)
=~- 正規表現一致
=~- 正規表現不一致
たとえば、次の規則は、ローカルのフェデレーション サーバーによって発行されていない、サフィックスが boeing.com の電子メール要求すべてを受け入れます。
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", value =~ "^.*@boeing\.com$" , issuer != "LOCAL AUTHORITY"] => issue(claim = c);
カスタム規則を作成するためのベスト プラクティス
次の表で説明するように、フィルターは、各要求の 1 つ以上のプロパティに適用できます。
| 要求のプロパティ | 説明 |
|---|---|
| Type | 要求の種類 (通常は、URI として表されます) には、要求で伝達する情報の種類に関するフェデレーション パートナー間の暗黙の同意が反映されます。 たとえば、種類 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress の要求には、ユーザーの電子メール アドレスが含まれます。 |
| 値 | クレームの値。 たとえば、種類 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress の要求は、johndoe@fabrikam.com の値を持つことができます。 |
| ValueType | ValueType は、要求の値に含まれる情報を解釈する方法を表します。 通常、ValueType は http://www.w3.org/2001/XMLSchema#string に設定されますが、要求値には、Base64Binary でエンコードされたデータ (イメージなど)、日付、ブール値などが含まれている場合があります。 |
| 発行者 | 発行者は、前回ユーザーに関する要求を発行したパーティです。 要求が要求プロバイダーのフェデレーション サーバーで取得された場合は、すべての要求の発行者が "LOCAL AUTHORITY" に設定されます。 フェデレーション プロバイダーのフェデレーション サーバーが要求を受信した場合、要求の発行者は、トークンに署名した要求プロバイダーの要求プロバイダー識別子に設定されます。 このため、要求プロバイダーから受信した要求の規則を処理するときは、すべての要求の発行者が同じ値に設定されます。 証明書利用者の規則を作成するとき、発行者のプロパティを使用して、別の要求プロバイダーから送信された要求を区別できます。 |
| OriginalIssuer | この要求プロパティの目的は、要求を最初に発行したフェデレーション サーバーを伝達することです。 要求の issuer プロパティは、前回トークンに署名したフェデレーション サーバーに設定されているため、最初の発行者は、要求が複数のフェデレーション サーバーを介して送信されるシナリオで役に立ちます (たとえば、フェデレーション プロバイダーのフェデレーション サーバーからトークンを受け取る証明書利用者は、どの要求プロバイダーのフェデレーション サーバーがユーザーを認証したかに関心がある可能性があります)。 |
| プロパティ | 上記で説明した 5 つのプロパティのほかに、名前付きプロパティを格納できるプロパティ バッグが各要求にあります。 これらのプロパティはトークンでシリアル化されません。また、1 台のフェデレーション サーバーのスコープ内の要求発行パイプラインのコンポーネント間で情報をやり取りする場合にのみ有効です。 たとえば、要求プロバイダー規則の処理中にプロパティを設定し、証明書利用者の規則でそのプロパティを参照します。 |