承認クレーム ルールをいつ使うべきか

  • [アーティクル]

このルールを Active Directory フェデレーション サービス (AD FS) 2.0 で使用できるのは、受信クレームの種類を取得してから、ルールで指定する値に基づいてユーザーのアクセスの許可または拒否を決定するアクションを適用する必要がある場合です。このルールを使用するときは、ルールで設定したいずれかのオプションに基づいて、次のルール ロジックに適合するクレームをパス スルーまたは変換します。

ルール オプション ルール ロジック
Permit All Users 受信クレームの種類が任意のクレームの種類に等しく、値が任意の値に等しい場合は、値が Permit であるクレームを発行する
Permit access to users with this incoming claim 受信クレームの種類が指定されたクレームの種類に等しく、値が指定されたクレームの値に等しい場合は、値が Permit であるクレームを発行する
Deny access to users with this incoming claim 受信クレームの種類が指定されたクレームの種類に等しく、値が指定されたクレームの値に等しい場合は、値が Deny であるクレームを発行する

以下のセクションでは、クレーム ルールの基本事項について説明します。また、いつこのルールを使用するかについても詳しく解説します。

クレーム ルールについて

クレーム ルールは、受信クレームを取得し、それに条件を適用し (x の場合は y を実行、という形式)、条件パラメーターに基づいて送信クレームを生成するというビジネス ロジックのインスタンスを表します。このトピックを読み進める前に、クレーム ルールについて、以下の重要事項を確認しておいてください。

  • AD FS 2.0 管理スナップインでクレーム ルールを作成するには、クレーム ルール テンプレートを使用する必要があります。

  • クレーム ルールは、クレーム プロバイダー (Active Directory または別のフェデレーション サービスなど) から直接送信された受信クレームを処理するか、クレーム プロバイダーの信頼に関する受け入れ変換ルールの出力から得られる受信クレームを処理します。

  • クレーム ルールは、1 つのルール セット内で古い順に、クレーム発行エンジンによって処理されます。ルールに優先順位を設定することで、指定されたルール セット内で先行するルールによって生成されたクレームをさらに絞り込んだり、フィルター処理することができます。

  • クレーム ルール テンプレートでは、常に受信クレームの種類を指定する必要があります。ただし、クレームの種類が同じ複数のクレーム値は 1 つのルールで処理できます。

クレーム ルールおよびクレーム ルール セットの詳細については、「クレーム ルールの役割」を参照してください。ルールの処理方法の詳細については、「クレーム エンジンの役割」 を参照してください。クレーム ルール セットの処理方法の詳細については、「クレーム パイプラインの役割」を参照してください。

Permit All Users

Permit All Users ルール テンプレートを使用すると、すべてのユーザーが証明書利用者にアクセスできます。ただし、追加の承認ルールを使用して、アクセスをさらに細かく制限できます。あるルールで証明書利用者へのユーザーのアクセスが許可され、別のルールでは拒否されている場合、拒否の結果が許可の結果に優先するため、ユーザーはアクセスを拒否されます。

フェデレーション サービスから証明書利用者へのアクセスが許可されているユーザーであっても、証明書利用者によってサービスを拒否される可能性があります。

Permit access to users with this incoming claim

Permit or Deny Users Based on an Incoming Claim ルール テンプレートを使用してアクセス許可のルールを作成し、条件を設定すると、受信クレームの種類と値に基づいて特定のユーザーに証明書利用者へのアクセスを許可できます。たとえば、このルール テンプレートを使用して、グループ クレームの値が Domain Admins であるユーザーにのみアクセスを許可するルールを作成できます。あるルールで証明書利用者へのユーザーのアクセスが許可され、別のルールでは拒否されている場合、拒否の結果が許可の結果に優先するため、ユーザーはアクセスを拒否されます。

フェデレーション サービスから証明書利用者へのアクセスが許可されているユーザーであっても、証明書利用者によってサービスを拒否される可能性があります。証明書利用者へのアクセスをすべてのユーザーに許可する場合は、Permit All Users ルール テンプレートを使用します。

Deny access to users with this incoming claim

Permit or Deny Users Based on an Incoming Claim ルール テンプレートを使用してアクセス拒否のルールを作成し、条件を設定すると、受信クレームの種類と値に基づいてユーザーから証明書利用者へのアクセスを拒否できます。たとえば、このルール テンプレートを使用して、グループ クレームの値が Domain Users であるすべてのユーザーのアクセスを拒否するルールを作成できます。

アクセス拒否条件を使用し、同時に特定ユーザーから証明書利用者へのアクセスを有効にする場合は、そのユーザーが証明書利用者にアクセスできるようにするためのアクセス許可条件を含む承認ルールを、後から明示的に追加する必要があります。

クレーム発行エンジンがルール セットを処理するとき、ユーザーがアクセスを拒否されると、その後のルール処理が停止され、AD FS 2.0 はユーザーの要求に "アクセス拒否" エラーを返します。

ユーザーを承認する

AD FS 2.0 では、承認ルールを使用して許可クレームまたは拒否クレームを発行します。この許可クレームまたは拒否クレームにより、(使用するクレームの種類に基づいて) ユーザーまたはユーザーのグループが、与えられた証明書利用者の Web ベース リソースへのアクセスを許可されるかどうかが決定されます。承認ルールは、証明書利用者の信頼に対してのみ設定できます。

承認ルール セット

構成するために必要な許可操作または拒否操作の種類に応じて、さまざまな承認ルール セットが存在します。これらのルール セットは次のとおりです。

  • 発行承認ルール: これらのルールは、ユーザーが証明書利用者のクレームを受け取ることができるかどうか、したがって、証明書利用者にアクセスできるかどうかを決定します。

  • 委任承認ルール: これらのルールは、ユーザーが証明書利用者に対して別のユーザーとして動作できるかどうかを決定します。ユーザーが別のユーザーとして動作している場合でも、要求元のユーザーに関するクレームは、通常どおりトークンに配置されます。

  • 偽装承認ルール: これらのルールは、ユーザーが証明書利用者に対して別のユーザーとして動作できるかどうかを決定します。証明書利用者にはユーザーが偽装されていることがわからないため、別のユーザーへの偽装はきわめて強力な機能です。

承認ルール プロセスをクレーム発行パイプラインにどのように適合させるかの詳細については、「クレーム発行エンジンの役割」を参照してください。

サポートされるクレームの種類

AD FS 2.0 は、2 つのクレームの種類を定義して、ユーザーのアクセスを許可するか拒否するかの決定に使用します。これらのクレームの種類の URI (Uniform Resource Identifier) は、次のとおりです。

  1. Permit: https://schemas.microsoft.com/authorization/claims/permit

  2. Deny: https://schemas.microsoft.com/authorization/claims/deny

このルールの作成方法

どちらの承認ルールの作成も、クレーム ルール言語を使用するか、AD FS 2.0 管理スナップインで [Permit All Users] ルール テンプレートまたは [Permit or Deny Users Based on an Incoming Claim] ルール テンプレートを使用します。Permit All Users ルール テンプレートには、構成オプションはありません。一方、Permit or Deny Users Based on an Incoming Claim ルール テンプレートには、次の構成オプションが用意されています。

  • クレーム ルール名を指定する

  • 受信クレームの種類を指定する

  • 受信クレームの値を入力する

  • この受信クレームを使用するユーザーのアクセスを許可する

  • この受信クレームを使用するユーザーのアクセスを拒否する

このテンプレートの作成方法に関する手順の詳細については、「AD FS 2.0 展開ガイド」の「すべてのユーザーを許可するためのルールを作成する」および 受信クレームに基づいてユーザーを許可または拒否するためのルールを作成する」(英語) を参照してください。

クレーム ルール言語を使用する

クレーム値がカスタム パターンと一致する場合にのみクレームを送信するようにする場合は、カスタム ルールを使用する必要があります。詳細については、「カスタム クレーム ルールを使用する場合」を 参照してください。

複数のクレームに基づいて承認ルールを作成する方法の例

クレーム ルール言語の構文を使用してクレームを承認する場合は、ユーザーの元のクレームに複数のクレームが存在するかどうかに基づいてクレームを発行することもできます。次のルールが承認クレームを発行するのは、ユーザーが Editors グループのメンバーであり、かつ Windows 認証で既に認証されている場合だけです。

[type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value == "urn:federation:authentication:windows" ] && [type == "https://schemas.xmlsoap.org/claims/Group ", value == “editors”] => issue(type = "https://schemas.xmlsoap.org/claims/authZ", value = "Granted");

フェデレーション サーバー プロキシの信頼を作成または削除できる権限を委任するための承認ルールを作成する方法の例

フェデレーション サービスでは、フェデレーション サーバー プロキシを使用してクライアント要求をリダイレクトする前に、まずフェデレーション サービスとフェデレーション サーバー プロキシ コンピューターの間で信頼を確立する必要があります。既定でプロキシの信頼が確立されるのは、次のいずれかの資格情報が AD FS 2.0 フェデレーション サーバー プロキシの構成ウィザードで正常に提供される場合です。

  • プロキシが保護するサービス アカウント (フェデレーション サービスで使用されます)

  • フェデレーション サーバー ファーム内のすべてのフェデレーション サーバー上でローカルの Administrators グループのメンバーとなっている Active Directory ドメイン アカウント

与えられたフェデレーション サービスに対してプロキシの信頼を作成できるユーザーを指定する場合は、次の委任方法のいずれかを使用できます。この方法の一覧は、最も安全で最も問題の少ない委任の方法として AD FS 2.0 製品チームが推奨する優先順位で並べられています。組織のニーズに合わせてこれらの方法のいずれか 1 つのみを使用する必要があります。

  1. Active Directory でドメイン セキュリティ グループ (たとえば、FSProxyTrustCreators) を作成し、このグループをファーム内の各フェデレーション サーバーのローカルの Administrators グループに追加し、権限の委任先のユーザー アカウントのみを新しいグループに追加します。これは最も推奨される方法です。

  2. ユーザーのドメイン アカウントをファーム内の各フェデレーション サーバーの管理者グループに追加します。

  3. 何らかの理由でこれらの方法のいずれも使用できない場合は、この目的のための承認ルールを作成することもできます。この方法は、このルールが正しく記述されていない場合に混乱が生じる可能性があるため、お勧めしません。カスタムの承認ルールを使用して Active Directory ドメイン ユーザー アカウントを指定することにより、指定されたフェデレーション サービスに関連付けられているすべてのフェデレーション サーバー プロキシの間の信頼を作成する権限だけでなく、削除する権限も委任することができます。

    3 番の方法を選択する場合は、次のルール構文を使用して、指定されたユーザー (この場合は contoso\frankm) を許可する承認クレームを発行し、フェデレーション サービスに対して、1 つ以上のフェデレーション サーバー プロキシの信頼を作成します。Windows PowerShell コマンドの Set-ADFSProperties AddProxyAuthorizationRules を使用して、このルールを適用する必要があります。

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", issuer=~"^AD AUTHORITY$" value == "contoso\frankm" ] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true") exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true"); c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value ); c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );

指定したユーザーを削除して、プロキシの信頼を作成できないようにする場合は、承認ルールをプロキシの信頼に関する既定の承認ルールに戻すと、ユーザーがフェデレーション サービスのプロキシの信頼を作成する権限を削除できます。Windows PowerShell コマンドの Set-ADFSProperties AddProxyAuthorizationRules を使用して、このルールを適用することも必要です。

exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true"); c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value ); c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );

クレーム ルール言語の詳細については、「クレーム ルール言語の役割」を参照してください。