認証コンテキスト テンプレートの設定

目次
casso1283
目次
2
認証コンテキスト テンプレートによって、パートナーがサポートする特定の SAML 2.0 AuthnContext URI が定義されます。各 URI は特定のコンテキスト クラスを識別します。パートナーシップごとにテンプレートを選択することができ、複数のパートナーシップで 1 つのテンプレートを使用できます。
共通の機能に加えて、テンプレートには各パートナーでの以下の個別の機能があります。
IdP
IdP が SP リクエストの認証コンテキストを自動的に検出するように設定されている場合は、IdP で認証コンテキスト テンプレートが必要です。
テンプレートは URI をユーザ セッションに関連付けられた保護レベルにマッピングします。保護レベルは、ポリシー サーバでの認証方式の強度(1 から最も強い 1000 まで)を示します。管理者は、ユーザを認証してユーザ セッションを確立する認証方式を設定する際に、保護レベルを割り当てます。
SP
SP での認証コンテキスト テンプレートは、認証リクエストで送信される認証コンテキストを生成するために必要です。SP はリクエストの生成後、IdP にそれを送信します。テンプレートは、受信したアサーションが認証コンテキスト リクエストを満たしていることを SP が検証するためにも必要です。
認証コンテキストの機能を設定する前に、以下の最小限の知識要件を満たしていることを確認します。
  • 認証コンテキスト処理に関連する SAML 2.0 標準に精通している。
  • フェデレーション設定オブジェクトについての理解。
  • 管理 UI のアクセス方法および使用方法についての知識。
以下の図は、各パートナーの設定プロセスを示しています。
SiteMinder
各サイトに をインストールする必要はありません。
設定_プロセス_認証コンテキスト
config_process_authncontext
認証コンテキストと強度レベルの決定
SP は、リクエストされたリソースへのアクセスを許可する前に、特定の認証コンテキスト クラスと強度レベルを必要とすることがあります。SP でのリソースの感度に基づいて、SP は IdP から受け取るアサーションに確信を持つ必要があります。
IdP および SP の管理者は、サポートされる認証コンテキストおよび各クラスの相対的強度のガイドラインを確立する必要があります。IdP でのクラスの順序は、関連付けられた強度レベルと共に、SP にどのように応答するかに影響します。
たとえば、SP が、3 の強度レベルの X.509 証明書の認証コンテキスト クラスをリクエストするとします。IdP は適切な強度レベルでリクエストしているユーザを認証する必要があります。SP からのリクエスト内の比較値は、認証コンテキストの評価を定義します。IdP が提供する認証コンテキストは、比較によって示される要件を満たす必要があります。強度レベルは、完全一致、最小または最大レベル、またはより高い強度レベルです。
認証コンテキスト テンプレートのセットアップ
認証コンテキスト処理を実装するために認証コンテキスト テンプレートをセットアップします。この手順はアイデンティティ プロバイダまたはサービス プロバイダで同じです。
以下の手順に従います。
  1. 管理 UI にログインします。
  2. [フェデレーション]-[パートナーシップ フェデレーション]-[認証コンテキスト テンプレート]を選択します。
    [認証コンテキスト テンプレートの表示]ウィンドウが開きます。
  3. [テンプレートの作成]を選択します。テンプレート ウィザードで最初の手順が開きます。
  4. テンプレートの名前を入力します。
  5. 以下の
    いずれか
    のアクションを実行します。
    手動で URI を入力し、[URI の追加]をクリックします。
    [デフォルト URI のロード]をクリックして事前定義済みリストから URI を選択します。[使用可能な URI]から[選択された URI]リストに URI を移動します。
  6. 強度レベルで、選択された URI を並べ替えます。強度レベルは、最強の URI が一番上で、最弱の URI が一番下の降順になります。
  7. [Next]をクリックします。
  8. (オプション)同じ強度レベルを必要とする URI を、前の URI の下に URI をインデントすることによってグループ化します。[グループ化の変更]矢印を使用して URI をグループへ、またはグループから移動させます。
  9. [保護レベルの有効化]をクリックします。
    保護レベルを認証方式から URI にマッピングします。保護レベルは、1 から最も強い 1000 までの範囲で認証方式の強度を示します。個々の URI が一意の保護レベルを持つことができますが、URI のグループ化とは、それらが同じ強さのレベルを持つことを意味します。
    保護レベルを降順に割り当てます。最強のコンテキストを上部に、および最弱のコンテキストを下部にして一覧表示します。最大の保護レベルを変更することができ、最小が自動計算されます。管理 UI は、各保護レベルに URI が関連付けられるように、レベルの範囲にギャップがないことを確認します。
    保護レベル割り当てについての詳細を参照してください。
  10. [完了]をクリックして設定を確認します。
テンプレートが完成しました。
認証コンテキスト テンプレート用の保護レベル割り当て
保護レベルとは、認証の強度の保証です。選択した各認証 URI に保護レベルを割り当てます。リストの各 URI の最大のレベルを指定します。最小の保護レベルは、リスト内の後続の URI の最大レベルに基づいて自動的に計算されます。この範囲は保護レベルを反映します。
保護レベルの割り当ては、設定されたポリシー サーバ認証方式の保護レベルを反映している必要があります。たとえば、ポリシー サーバが 20 の保護レベルで X.509 認証方式を使用している場合は、テンプレートに指定されている範囲に 20 が含まれることを確認します。最後に、ポリシー サーバは、保護レベルに基づいて URI の強度レベルを生成します。
保護レベルの例
ポリシー サーバで設定される認証方式
保護レベル
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
20
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
15
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
10
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
5
各 URI について、ポリシー サーバは保護レベルを URI の強度レベルに自動的にマッピングします。範囲は、認証方式の保護レベルを対象にします。例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">
  • X509 方式では、保護レベル 16 ~ 1000 を対象にします
  • MobileTwoFactorContract では 11 ~ 15 の保護レベルを対象にします。
  • インターネットプロトコルでは 6 ~ 10 を対象にします
  • パスワードでは 1 ~ 5 を対象にします
各保護レベルは、以下の表に示すように、URI の強度レベルにマップされます。
URI
保護レベル最大
URI 強度
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
1000
4
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
15
3
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
10
2
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
5
1
複数の URI をグループ化すると、グループ化によって、異なる保護レベルを持つ URI が同じ URI 強度を持つことができます。以下の変更された表にグループ化を示します。
URI
保護レベル最大
URI 強度
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
1000
3
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
800
3
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
700
2
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
200
1
強度レベルの範囲は、リスト内の総グループ数を反映します。たとえば 3 つのグループがある場合、強度レベルの範囲は 1 から総グループ数の 3 です。