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

3
casso1283
3
以下の図は、各パートナーの設定プロセスを示しています。各サイトに
SiteMinder
は必要ありません。
動的認証テンプレートの設定
dynamic authentication template configuration
認証コンテキスト処理を設定するには、以下の手順に従います。
  1. パートナーとの認証コンテキストおよび強度レベルを決定します。
  2. 認証コンテキスト テンプレートをセットアップします。
  3. サイトのタスクを実行します。
    • IdP から SP へのパートナーシップで認証コンテキスト処理を有効にします。
    • SP から IdP へのパートナーシップで認証コンテキスト リクエストを有効にします。
パートナーとの認証コンテキストと強度レベルの決定
SP は、リクエストされたリソースへのアクセスを許可する前に、特定の認証コンテキストと強度レベルを必要とすることがあります。SP でのリソースの感度に基づいて、SP は IdP から受け取るアサーションに確信を持つ必要があります。
IdP および SP の管理者は、サポートされる認証コンテキストおよび各認証コンテキスト URI の相対的強度のガイドラインを確立する必要があります。IdP での URI の順序は、関連付けられた強度レベルと共に、IdP が SP にどのように応答するかに影響します。
たとえば、SP が、X.509 証明書および完全一致の比較値の認証コンテキストをリクエストするとします。IdP はリクエストしたユーザを適切な強度レベルで認証し、認証コンテキストの評価中に比較値を満たす必要があります。
認証コンテキスト テンプレートのセットアップ
認証コンテキスト テンプレートによって、パートナーがサポートする特定の SAML 2.0 AuthnContext URI が定義されます。テンプレートで、各 URI に保護レベル範囲を割り当てます。これは強度レベルにマップされます。
テンプレートには、各パートナーでの以下の個別の機能があります。
IdP
認証コンテキスト テンプレートは、パートナーシップで動的認証が有効になっている場合に IdP で必要です。テンプレートは URI をユーザ セッションに関連付けられた保護レベルにマッピングします。各 URI は、認証 URL にもマップされます。
保護レベルは、1 から 1000 (最も強い)までの認証の強度を示します。管理者は、ユーザ セッションが確立されたスキームの強度を示すために認証スキームに保護レベルを割り当てます。
IdP は最初にテンプレートを使用して、ユーザ セッションの強度を判定します。IdP は、SP 認証リクエストで URI の強度を判断するためにテンプレートを使用します。これで、これらの強度レベルが比較されます。
SP
SP は、認証コンテキスト テンプレートを使用して、IdP に認証リクエストで送信される認証コンテキストを生成します。SP は、アサーション内の認証コンテキストが SP がリクエストしたコンテキストを満たしていることを検証するためにテンプレートを使用できます。
認証コンテキスト テンプレートを設定するための手順は、アイデンティティ プロバイダの場合もサービス プロバイダの場合も同じです。ただし、動的認証を使用するには、IdP でのみテンプレートに対して有効します。この機能を SP で有効にする必要はありません。パートナーシップごとにテンプレートを選択することができ、複数のパートナーシップで 1 つのテンプレートを使用できます。
SiteMinder
IdP および SP のテンプレートは一致する必要があります。これにより、各 URI に割り当てられた保護レベルが同じになります。
以下の手順に従います。
  1. 管理 UI にログインします。
  2. [フェデレーション]-[パートナーシップ フェデレーション]-[認証コンテキスト テンプレート]を選択します。
    認証コンテキスト テンプレート リストが表示されます。
  3. [テンプレートの作成]を選択します。
    テンプレート ウィザードで最初の手順が開きます。
  4. テンプレートの名前を入力します。
  5. [デフォルト URI のロード]をクリックし、事前定義済みリストから URI を選択します。 
    1. [使用可能な URI]から[選択された URI]リストに URI を移動します。
    2. 強度レベルで、選択された URI を並べ替えます。強度レベルは降順に表示されます。最も強い強度の URI が一番上で、最も弱い URI が一番下になります。
    3. (オプション)[クラス URI]フィールドにカスタム URI を指定できます。URI を入力し、[URI の追加]をクリックします。[使用可能な URI]から[選択された URI]リストにカスタム URI を移動させます。 
  6. [次へ]をクリックして続行します。
  7. URI に保護レベルを割り当てます。保護レベルは、1 から 1000 (最も強い)までの範囲で認証方式の強度を示します。個々の URI が固有の保護レベルを持つことができますが、URI をグループ化すると、それらが同じ強度レベルを持つことになります。
    保護レベルを割り当てる場合は、以下の情報を考慮してください。
    • 保護レベルを降順に割り当てます。最強のコンテキストを上部に、および最弱のコンテキストを下部にして一覧表示します。
    • 最大の保護レベルを変更することができ、最小保護レベルは自動的に計算されます。管理 UI は、各保護レベルに URI が関連付けられるように、レベルの範囲にギャップがないことを確認します。
    • (オプション)同じ強度レベルを必要とする URI をグループ化します。強度を同じにすることはできますが、保護レベルの範囲は異なる必要があります。URI をグループ化するには、前の URI の下に 1 つの URI をインデントします。URI をグループ間で移動させるには、[強度グループ化の変更]矢印を使用します。 
  8. [次へ]をクリックして続行します。
  9. (オプション) IdP で[動的認証の有効化]をクリックし、各 URI を認証 URL にマップします。この機能を有効にしたくない場合は、次の手順にスキップします。SP では、この設定は必要ありません。
    動的認証詳細テーブルに入力する方法
    1. テーブル内の各 URI のコンテキストに、一意の認証 URL を指定します。各 URL は一意である必要があります。URL が適切な URL 構文に準拠していることを確認します。
    2. 1 つのエントリをデフォルト認証エントリとして選択します。認証コンテキストが SP リクエストで送信されない場合、デフォルト エントリが使用されます。デフォルトは、アサーションの生成に必要な最小の認証レベルです。
    3. テーブル内の各認証 URL をポリシーで保護します(16 ページを参照)。認証 URL を保護すると、ユーザに対するチャンレジが発生します。ユーザがログインすると、セッションが確立します。セッションに使用する認証方式で各ポリシーを設定します。
  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
強度
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 が同等であると見なされることを意味します。以下の変更されたテーブルは、X.509 URI および MobileTwoFactorContract 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
900
3
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
700
2
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
299
1
強度レベルの範囲は、リスト内の総グループ数を反映します。たとえば 3 つのグループがある場合、強度レベルの範囲は 1 から総グループ数の 3 です。
テンプレート内の各認証 URL の保護
アクセス保護ポリシーは、認証チャレンジをトリガするためにテンプレート内の認証 URL をすべて保護する必要があります。ユーザが認証された後、ポリシー内の認証スキームによって確定された認証レベルでセッションが確立されます。
以下の手順に従います。
  1. 管理 UI にログインします。
  2. [インフラストラクチャ]-[エージェント]-[エージェントの作成]を選択します。
    アサーティング パーティ Web サーバに対して定義されたレルムにバインドするには、Web エージェントを作成します。Web サーバに対して一意のエージェント名を割り当てます。
  3. [ポリシー]-[ドメイン]-[ドメイン]-[ドメインの作成]を選択します。
    認証 URL 用のポリシー ドメインを作成します。チャレンジを要求されるユーザが含まれるユーザ ディレクトリを追加します。
  4. ポリシー ドメインに含まれるリソースへのアクセス権が必要なユーザを選択します。
  5. [レルム]タブを選択し、次の値を使用してポリシー ドメインのレルムを定義します。
    エージェント
    : アサーティング パーティ Web サーバのエージェント。このエージェントは、手順 2 で作成しています。
    リソース フィルタ
    : 認証チャンレンジを実装するアプリケーションの場所を指定します。アプリケーションが、サーブレット コンテナに展開されていることを確認します。たとえば、
    SiteMinder
    Web エージェントおよび
    フェデレーション ゲートウェイのデフォルトの場所は /affwebservices/redirectjsp です。redirectjsp アプリケーションは、各認証 URL に対して一意のフォルダの場所に配置することにより、複数回使用することができます。
    デフォルト リソース保護
    : 保護あり
    認証方式
    : ユーザ セッションに必要な認証方式を選択します
    永続セッション
    : HTTP-Artifact プロファイルのレルム ダイアログ ボックスの[セッション]セクションにある[永続]チェック ボックスをオンにして、セッション情報を格納します。セッション情報は、シングル ログアウトなどの機能、および属性機関に必要です。
  6. レルム ダイアログ ボックスの[ルール]セクションで、[ルールの作成]をクリックします。フィールドに以下の値を入力します。
    リソース/*
    : アスタリスクは、ルールがレルム内のすべてのリソースに適用されることを意味します。 
    許可/拒否と有効/無効
    許可アクセス
    [有効]チェック ボックスはオン
    アクション
    Web エージェント アクション
    Get、Post、Put
  7. [ポリシー]タブを選択し、次のコンポーネントが含まれるポリシーを作成します。
    • ユーザ ディレクトリで選択したユーザのセット。
    • redirectjsp アプリケーションなどのアプリケーションおよび関連ルールが含まれるレルム。
ポリシーが各認証 URL を保護するようになりました。ユーザがこの URL にリダイレクトされると、認証チャレンジがトリガされます。最終的に、セッションが作成されます。