次の方法で共有


パススルーまたはフィルター要求規則を使用する場合

特定の種類の受信要求を実行し、受信要求の値に基づいて出力を決定するアクションを適用する必要がある場合は、Active Directory フェデレーション サービス (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 つ以上のプロパティに適用できます。

プロパティを主張する 説明
タイプ 要求の種類 (通常は 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 は、要求の Value に含まれる情報を解釈する方法を表します。 通常、ValueType は http://www.w3.org/2001/XMLSchema#string に設定されますが、要求値には Base64Binary でエンコードされたデータ (画像など) や日付、ブール値などが含まれる場合があります。
発行者 発行者は、ユーザーに関する要求を最後に発行したパーティを表します。 要求がクレーム プロバイダーフェデレーション サーバーで取得された場合、すべての要求の発行者は "LOCAL AUTHORITY" に設定されます。 要求がフェデレーション プロバイダー フェデレーション サーバーによって受信された場合、要求の発行者は、トークンに署名したクレーム プロバイダーのクレーム プロバイダー識別子に設定されます。 したがって、要求プロバイダーから受信した要求に対する規則を処理する場合、すべての要求の発行者は同じ値に設定されます。 証明書利用者の規則を作成する場合、発行者プロパティを使用して、異なるクレーム プロバイダーからの要求を区別できます。
元の発行者 この要求プロパティは、最初に要求を発行したフェデレーション サーバーを伝えるために使用されます。 要求の発行者プロパティはトークンに署名した最後のフェデレーション サーバーに設定されるため、元の発行者は、要求が複数のフェデレーション サーバーを通過したシナリオで役立ちます (たとえば、フェデレーション プロバイダーのフェデレーション サーバーからトークンを受信する証明書利用者は、ユーザーを認証した特定のクレーム プロバイダーフェデレーション サーバーに関心がある可能性があります)。
特性 上で説明した 5 つのプロパティに加えて、各要求には名前付きプロパティを格納できるプロパティ バッグもあります。 これらのプロパティはトークンでシリアル化されず、単一のフェデレーション サーバーのスコープ内で要求発行パイプラインのコンポーネント間で情報を渡す場合にのみ意味があります。 たとえば、クレーム プロバイダー規則の処理中にプロパティを設定し、証明書利用者の規則でそれを参照します。