受信要求の種類を送信要求の種類にマップし、受信要求で発生した値に基づいて出力を決定するアクションを適用する必要がある場合は、Active Directory フェデレーション サービス (AD FS) でこの規則を使用できます。 このルールを使用する場合は、次の表に示すように、ルールで構成したオプションのいずれかに基づいて、次のルール ロジックに一致する要求をパススルーまたは変換します。
| 規則のオプション | ルール ロジック |
|---|---|
| すべての受信クレームを通過させる | 受信要求の種類が指定された要求の種類と等しく、値が任意の値と等しい場合は、指定された要求の種類と等しい送信要求の種類で要求を渡します |
| 受信要求の値を別の送信要求値に置き換える | 受信した要求の種類が指定された要求の種類であり、値が指定された要求値と等しい場合、新しい要求値指定された要求値と送信要求の種類指定された要求の種類で要求を変換します。 |
| 受信した電子メール サフィックス要求を新しい電子メール サフィックスに置き換える | 入力要求の種類が指定された要求の種類と値が任意のサフィックス値に等しい場合は、新しい送信要求値指定のサフィックス値を用いて、送信要求の種類を指定された要求の種類に変換します。 |
次のセクションでは、要求規則の基本的な概要と、この規則を使用するタイミングの詳細について説明します。
要求規則について
要求規則は、受信要求を受け取り、条件を適用し (x の場合は y の場合)、条件パラメーターに基づいて送信要求を生成するビジネス ロジックのインスタンスを表します。 次の一覧では、このトピックの詳細を読む前に要求規則について知っておくべき重要なヒントの概要を示します。
AD FS 管理スナップインでは、要求規則は要求規則テンプレートを使用してのみ作成できます
要求規則は、要求プロバイダー (Active Directory や別のフェデレーション サービスなど) から直接、または要求プロバイダー信頼に対する受け入れ変換規則の出力から受信要求を処理します。
要求規則は、特定の規則セット内の時系列の順序で要求発行エンジンによって処理されます。 ルールに優先順位を設定することで、特定のルール セット内の以前のルールによって生成された要求をさらに絞り込んだり、フィルター処理したりできます。
要求規則テンプレートでは、常に受信要求の種類を指定する必要があります。 ただし、1 つの規則を使用して、同じ要求の種類を持つ複数の要求値を処理できます。
要求規則と要求規則セットの詳細については、「#B0 要求規則の役割 #A1」を参照してください。 ルールの処理方法の詳細については、「 要求エンジンの役割」を参照してください。 要求規則セットの処理方法の詳細については、「要求パイプラインの役割」を参照してください。
すべての要求値をパススルーする
このアクションを使用する場合、指定した受信要求の種類にキーが設定されているすべての受信要求値は、フェデレーション サービスによって署名されたトークンに送信要求として送信される前に、指定された送信要求の種類にマップされます。
たとえば、[ すべての要求値を渡す ] オプション ロジックを使用してルールを設定し、グループの受信要求の種類とロールの送信要求の種類を指定すると、発行者から送信されるすべての受信要求値が、要求の種類が Role の新しい送信要求に個別にコピーされます。
要求の変換
AD FS では、要求 変換 という用語は、1 つの受信要求値を別の送信要求値に置き換えることを意味します。 この関数を可能にするのは、受信要求の変換規則です。 この規則のプロパティ内で、指定した受信要求の種類に基づいて異なる送信要求値を使用して受信値を変換する条件を設定できます。
たとえば、次の図に示すように、受信値を別の出力方向の要求値に置き換える条件でルールが設定されている場合、Group のすべての受信要求の種類は、新しい送信要求の種類のロールにマップされます。 この場合、購入者の受信要求値は、管理者の新しい送信要求値に置き換えられます。
このルールを使用して、すべての受信要求を指定した電子メール サフィックス値に新しい値に置き換える条件を適用することもできます。 たとえば、sales.corp.fabrikam.com のサフィックスを持つすべての要求値を fabrikam.com に変更する条件をこの規則で設定できます。
クレームプロバイダーの信頼関係にこの規則を設定する
クレーム プロバイダーの信頼を使用する場合、この規則は、要求プロバイダーからの受信要求を信頼できる同等の要求に変換するように構成できます。 要求の種類または要求の値は、組織内のクレーム プロバイダー組織とは異なる意味を持つことができます。 この規則を使用すると、要求プロバイダーの要求の種類と値を正規化できます。これにより、その出力方向の要求と同等のものを証明書利用者が理解することができます。
証明書利用者の信頼でのこの規則の構成
証明書利用者信頼を使用する場合、この規則は、特定の証明書利用者の要求を変換するように構成できます。 要求の種類または要求の値は、特定の証明書利用者にとって異なる意味を持つ場合があり、この規則により、1 つの証明書利用者の送信要求の種類と値を変更できます。
このルールを作成する方法
この規則は、要求規則言語を使用するか、AD FS 管理スナップインの 受信要求 規則テンプレートを使用して作成します。 このルール テンプレートには、次の構成オプションが用意されています。
要求規則名を指定する
特定の受信要求の種類を指定した送信要求の種類に変換する
すべての要求値をパススルーする
受信要求の値を別の送信要求値に置き換える
受信した電子メール サフィックス要求を新しい電子メール サフィックスに置き換える
このテンプレートを作成する方法の詳細については、「AD FS 展開ガイド」の 「受信要求を変換する規則を作成 する」を参照してください。
要求規則言語の使用
送信要求を複数の受信要求の内容から作成する必要がある場合は、代わりにカスタム規則を使用する必要があります。 送信要求の要求値が受信要求の値に基づいている必要がありますが、追加のコンテンツがある場合は、そのコンテキストでもカスタム規則を使用する必要があります。 詳細については、「 カスタム要求規則を使用する場合」を参照してください。
変換規則の構文を構築する方法の例
要求規則言語構文を使用して要求を変換する場合は、変換された要求のプロパティを新しいリテラル値に設定できます。 たとえば、次の規則では、同じ要求の種類を維持しながら、ロール要求の値を "Administrators" から "root" に変更します。
c:[type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/role", value == "Administrators"] => issue(type = c.type, value = "root");
正規表現は、要求変換にも使用できます。 たとえば、次の規則では、DOMAIN\USER 形式の Windows ユーザー名要求のドメインが FABRIKAM に設定されます。
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(type = c.type, value = regexreplace(c.value, "(?<___domain>[^\\]+)\\(?<user>.+)", "FABRIKAM\${user}"));
カスタム ルールを作成するためのベスト プラクティス
要求変換は、基本的なフィルター処理機能を使用して選択した要求に選択的に適用できます。 フィルター処理に使用される各要求プロパティには値を割り当てることができます。次の注意事項があります。
| プロパティを主張する | 説明 |
|---|---|
| Type、Value、ValueType | これらのプロパティは、割り当てに最も頻繁に使用されます。 変換された結果の要求には、少なくとも型と値を指定する必要があります。 |
| 発行者 | 要求規則言語では要求の発行者を設定することができますが、これは一般に推奨されません。 クレームの発行者はトークンにシリアライズされません。 トークンを受信すると、すべての要求の Issuer プロパティが、トークンに署名したフェデレーション サーバーの識別子に設定されます。 したがって、規則で要求の発行者を設定すると、トークンの内容に影響を与えず、要求がトークンにパッケージ化されると設定は失われます。 クレームの発行者の設定が理にかなっている唯一のシナリオは、要求プロバイダー規則セットの特定の値に設定され、証明書利用者規則セットがこの特定の値を参照する規則で作成される場合です。 Issuer プロパティが要求規則の値に明示的に設定されていない場合、要求発行エンジンはそれを "LOCAL AUTHORITY" に設定します。 |
| 元の発行者 | Issuer と同様に、OriginalIssuer には通常、値を明示的に割り当てないようにする必要があります。 発行者とは異なり、OriginalIssuer プロパティはトークンでシリアル化されますが、トークン コンシューマーが期待するのは、設定されている場合、最初に要求を発行したフェデレーション サーバーの識別子が含まれるということです。 |
| 特性 | 前のセクションで説明したように、要求のプロパティ バッグはトークンに保持されないため、プロパティへの割り当ては、後続のローカル ポリシーがプロパティに格納されている情報を参照する場合にのみ行う必要があります。 |
要求規則言語の使用方法の詳細については、「要求規則 言語の役割」を参照してください。