Cisco ACE XML Gateway ユーザ ガイド
サービスへの アクセス コントロール
サービスへのアクセス コントロール
発行日;2012/02/01 | 英語版ドキュメント(2009/11/20 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

サービスへのアクセス コントロール

アクセス コントロールの概要

複数の認証と認証メディエーションについて

.NET での認証

オーセンティケータと権限付与グループでの作業

オーセンティケータと権限付与グループの作成

オーセンティケータと権限付与グループの削除

オーセンティケータの権限付与グループの変更

サービスのプロビジョニング

クレデンシャル要件の指定

IP アドレス条件

SSL/TLS 証明書条件

SSL 証明書フィンガープリントによる検証

SSL 認証局による検証

LDAP クエリーによる検証

HTTP(S) Basic 認証条件

WSS Username/Password トークン条件

WSS Password Digest 条件

SAML トークン条件

XPath Password 条件

セキュリティ トークン条件

Time-of-Day 条件

パスワード ベースのクレデンシャルの検証

Active Directory LDAP クエリーでのクレデンシャルの検証

Active Directory LDAP クエリー検証の設定

LDAP でのクレデンシャルの検証

LDAP バインド パスワード検証の使用

LDAP クエリー パスワード検証の使用

オーセンティケータごとの XML セキュリティ公開鍵の使用

ID 報告

ID 報告機能のイネーブル化

ユーザ アクティビティ情報の表示

サービスへのアクセス コントロール

この章では、ACE XML Gateway で公開されているサービスへのアクセスを制御する方法について説明します。内容は次のとおりです。

「アクセス コントロールの概要」

「オーセンティケータと権限付与グループでの作業」

「サービスのプロビジョニング」

「クレデンシャル要件の指定」

「パスワード ベースのクレデンシャルの検証」

「オーセンティケータごとの XML セキュリティ公開鍵の使用」

「ID 報告」

アクセス コントロールの概要

ACE XML Gateway と Manager が、アプリケーション ネットワークでのアクセス コントロール要件を構成したり実施したりするための豊富な一連の機能を提供します。ACE XML Gateway は、SSL 認証、Security Assertion Markup Language(SAML)、Web Services Security(WSS)UsernameToken、さまざまな形式のユーザ名/パスワードなど、幅広いタイプの認証をチェックすることができます。ACE XML Gateway は、認証データ自体を確認することもできれば、LDAP ディレクトリや SOAP サービスなどの外部リソースを使用することもできます。

ACE XML Gateway の独創的な機能は ACE XML Gateway SDK で補完できます。SDK を使用すれば、ポリシーに新しい認証タイプと認証メカニズムを定義できます。SDK の詳細については、 Cisco ACE XML Gateway Developer Guide を参照してください。

複数の認証と認証メディエーションについて

認証メディエーションでは、受信したクレデンシャルが、外部へ配信するために 1 つの形式から他の形式に変更されます。ACE XML Gateway は、HTTP Basic 認証、NTLM ヘッダー、WSS UsernameToken、SAML トークンなどのさまざまな形式のクレデンシャルを扱えます。送信元のクレデンシャルは、ユーザ名/パスワード タイプのクレデンシャル、SAML Token Subject NameIdentifier、SSL 認証の DN、その他のどのタイプでもかまいません。

認証メディエーションは、受信クレデンシャルを持つバックエンド サービス認証を送信クレデンシャルの送信元として設定することによりセットアップできます。

特定のタイプのクレデンシャルについては、与えられたメッセージにそのタイプのクレデンシャルの 2 つ以上のインスタンスを入れることが適切な場合もあります。たとえば、1 つの要求が、その要求の構成に寄与した複数の参加メンバのそれぞれを識別するために複数のクレデンシャルを使用する場合があります(一方で、IP アドレスなどのその他のタイプのクレデンシャルは、1 つの要求の中で 1 度しか意味を持って出現することができません)。ACE XML Gateway は、1 つの要求で複数のクレデンシャルを評価し、処理することができます。複数クレデンシャルモードは、WSS UsernameToken および SAML のクレデンシャルに使用可能です。

複数クレデンシャルモードが最小クレデンシャル要件を要求するというわけではないので注意してください。つまり、クレデンシャルを持たない要求も、複数クレデンシャルモードのオーセンティケータで受け付けられる場合があります。これを使用するのは、複数のクレデンシャルが存在した場合には複数のクレデンシャルを評価するけれども、必ずしも複数のクレデンシャルが存在している必要はないという状態を意図している場合だけにしてください。このため、ACE XML Manager は、すでに複数クレデンシャルモードでその他の任意のオーセンティケータにプロビジョニングされているハンドラを管理者がプロビジョニングすることを禁止します。これを行おうとすると、「A handler that is provisioned to an authenticator that uses optional credentials cannot be provisioned to any additional authenticators.」というポリシー コンパイル警告が発生します。

クレデンシャル メディエーションは、複数のクレデンシャルを持つメッセージに使用可能です。一般に、ACE XML Gateway でサポートされる複数のクレデンシャルを処理するシナリオには、次のようなものがあります。

受信要求のユーザ名/パスワードクレデンシャルから発信要求の認証情報タイプである WSS UsernameToken、HTTP Basic 認証、または SAML トークンのクレデンシャルへのマッピング。

複数の WSS UsernameToken クレデンシャル値から SAML アサーションへのマッピング。 UsernameToken 要素のカスタムアトリビュート(つまり、WSS 名前空間内にないアトリビュート)が、生成された SAML アトリビュート文内のアトリビュートにも同様にマッピングできます。

複数の SAML アサーションをチェックし、そのアサーションを通過または排除する。

LDAP ルックアップで取得したユーザ アトリビュートから複数の SAML アサーションへのマッピング。

クレデンシャル メディエーションとバックエンド認証セットアップの詳細については、 第 7 章「バックエンド システムへの認証要求」 を参照してください。

.NET での認証

.NET では、クライアントは、通常、その最初の要求を認証クレデンシャルなしで送信します。クライアントは、 WWW-Authenticate: Basic ヘッダーを持つ HTTP 401 応答が送り返されてきた場合にクレデンシャルを提供するものとされています。デフォルトでは、ACE XML Gateway は、このヘッダーを権限付与エラー応答に入れて、.NET クライアントに以降の要求でクレデンシャルを提供するように促します。

バックエンドから HTTP Basic 認証を要求される .NET インフラストラクチャの設定値を設定する際には、サービス記述子を渡すように設定してください。これを行うには、サービス認証コンフィギュレーションで、オプション Send Basic Auth header with username and password from consumer credential を選択します。

詳細については、 第 7 章「バックエンド システムへの認証要求」 を参照してください。

オーセンティケータと権限付与グループでの作業

サービスへのアクセス条件を定義するには、オーセンティケータと呼ばれるポリシー オブジェクトを使用します。オーセンティケータには、1 つまたは複数のクレデンシャル タイプに基づいたアクセス条件が含まれます。オーセンティケータ内で定義された条件は、権限付与グループと呼ばれる別のポリシー オブジェクトを通じてサービス アクセスに適用されます。権限付与グループ内にオーセンティケータを作成した後、権限付与グループを仮想サービスと関連付けることにより、その要件をサービスに適用します。

図 6-1 に、[Access Control] ページでのオーセンティケータ、権限付与グループ、およびハンドラの表示を示します。

図 6-1 オーセンティケータ、権限付与グループ、およびハンドラ

 

オーセンティケータと権限付与グループの作成

アクセス コントロール ルールのセットアップでの最初の手順は、オーセンティケータの作成です。オーセンティケータを作成する手順は次のとおりです。


ステップ 1 Web コンソールに Administrator または Access Control ロールを持つ Privileged ユーザとしてログインし、操作メニューの [Access Control Browser] リンクをクリックします。

ポリシー内に何らかのハンドラまたは基本仮想サービスがあった場合は、それらがアクセス コントロール ブラウザ(図 6-2)に表示されます。これらは、アクセス ステータス(プロビジョニングされていない(アクセス不可)、公開されている、権限付与グループに割り当てられているのいずれか)ごとに表示されます。

図 6-2 アクセス コントロール ブラウザ

 

ステップ 2 [Add an Authenticator] ボタンをクリックします。

ステップ 3 [Edit General Information] ページで、[Authenticator Name] フィールドにオーセンティケータの名前を入力します。この名前は成功したアクセス試行のイベントおよびメッセージ トラフィック ログの説明の中で使用されるため、わかりやすい名前にしてください。

XML セキュリティ公開鍵をオーセンティケータと関連付ける場合は、オーセンティケータの名前を指定する必要はありません。そのオーセンティケータに関連したログ イベントやその他のアクティビティは、該当する要求について確認されたクライアント証明書内の Common Name(CN)で識別できます。XML セキュリティ公開鍵をオーセンティケータに関連付ける手順は、次のとおりです。

a. [Advanced Options] コントロールを展開します。

b. [Set the name of this authenticator to the CN from this Consumer Certificate] チェックボックスをクリックします。


) 詳細については、「オーセンティケータごとの XML セキュリティ公開鍵の使用」を参照してください。


ステップ 4 オーセンティケータの追加先とする権限付与グループを指定します。

オーセンティケータを既存の権限付与グループに追加するには、[Authorization Group] メニューからグループを選択します。このオーセンティケータの条件を満たす要求は、その既存権限付与グループに関連付けられているサービスにアクセスできることになるので注意してください。

オーセンティケータを入れる新しい権限付与グループを作成するには、[Authorization Group] メニューで [Create in new authorization group named] を選択した状態で、[Authorization Group] メニューの横にあるフィールドに新しい権限付与グループの名前を入力します。

ステップ 5 [Create] をクリックして、作業ポリシーにオーセンティケータを追加します。


 

デフォルトでは、アクセス条件を持たないオーセンティケータはすべての要求をブロックします。アクセス条件の追加については、「クレデンシャル要件の指定」を参照してください。アクセス条件を追加したら、「ID 報告」の説明に従って、ID 報告機能の設定を行えます。

オーセンティケータと権限付与グループの削除

権限付与グループは、オーセンティケータを 1 つも含まず、参照している仮想サービスもない場合にだけ削除できます。何かある場合は、権限付与グループを削除する前にその依存関係を削除する必要があります。

基本的に、依存関係は次のようにして削除できます。

権限付与グループとハンドラの関係を削除するには、権限付与グループの名前をクリックし、表示されたページ内の表で、それにプロビジョニングされているすべてのハンドラのチェックを外します。

オーセンティケータを削除するには、アクセス コントロール ブラウザでオーセンティケータの名前をクリックし、ページの下端にある [Delete This Authenticator] ボタンをクリックします。

権限付与グループを削除するには、アクセス コントロール ブラウザで権限付与グループの名前をクリックし、ページの下端にある [Delete Authorization Group] ボタンをクリックします。

オーセンティケータの権限付与グループの変更

「オーセンティケータと権限付与グループの作成」で説明したように、オーセンティケータを作成する際には、それを所属させる権限付与グループを指定する必要があります。既存オーセンティケータの権限付与グループは、次のようにして後から変更することができます。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス コントロール ブラウザで、設定を行うオーセンティケータの名前をクリックします。

ステップ 3 [Authenticator] 情報ページで、[General] セクションの [Edit] リンクをクリックします。

ステップ 4 [Authorization Group] メニューで、オーセンティケータの新しい権限付与グループを選択します。

オーセンティケータは同時に 1 つの権限付与グループにしか属せないため、新しいグループに追加すると、以前のグループからは削除されます。

ステップ 5 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

サービスのプロビジョニング

オーセンティケータを作成したら、それを(権限付与グループを通じて)仮想サービスに関連付けることにより、その条件を実施できます。オーセンティケータを仮想サービスに関連付けるには、次のようないくつかの要件があります。

オーセンティケータが、その仮想サービスのプロトコルでサポートされている認証タイプの条件だけを含んでいなければなりません。たとえば、SAML などの XML ベースのクレデンシャルを要求するオーセンティケータは、SOAP、HTTP Post Body などの XML プロトコルに基づいたサービスにしか割り当てることができません。

クレデンシャルが SOAP ヘッダー(WSS UsernameToken、SAML トークンなど)として渡される場合、仮想サービスでの SOAP ヘッダーの処理がイネーブルになっていなければなりません。そうなっていないと、ポリシー コンパイル エラーが発生して、ポリシーを導入できません。

権限付与グループを通じてオーセンティケータを仮想サービスに適用する手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス コントロール ブラウザで、プロビジョニングする仮想サービスまたはハンドラの名前をクリックします。

ステップ 3 [Access is restricted to the following authorization groups] ボタンをクリックします。[Allow Access] カラムのチェックボックスをイネーブルにします。

または、[Public] ボタンをクリックして、制限のない公開アクセスを指定することもできます。ユーザがサービスにアクセスできないようにするには、[No access] ボタンをクリックします。

ステップ 4 権限付与グループに含まれるアクセス条件を仮想サービスに課すには、その権限付与グループのチェックボックスをクリックします。権限付与グループは、必要な数だけ選択できます。

ステップ 5 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

ポリシーを導入した後は、オーセンティケータの要件を満たす要求だけがサービスへのアクセスを許可されます。

クレデンシャル要件の指定

オーセンティケータが、サービスにアクセスするための条件を定義します。ACE XML Gateway は、次のタイプのアクセス条件をサポートしています。

「IP アドレス条件」

「SSL/TLS 証明書条件」

「HTTP(S) Basic 認証条件」

「WSS Username/Password トークン条件」

「WSS Password Digest 条件」

「SAML トークン条件」

「XPath Password 条件」

「セキュリティ トークン条件」

「Time-of-Day 条件」

1 つのオーセンティケータに、クレデンシャルの異なる複数のタイプに基づいて複数の条件を入れることができます。要求は、オーセンティケータに受け付けられるには、オーセンティケータに含まれるすべての条件を満たしていなければなりません。つまり、オーセンティケータ内の条件は、論理 AND で結ばれます。論理 OR 条件を作成するには、1 つのサービスに複数のオーセンティケータを使用します。この場合、いずれか 1 つのオーセンティケータのすべての条件を満たしていれば、要求は受け付けられます。

組み込みのクレデンシャル タイプは、シスコ提供のビルド済みの拡張機能、および ACE XML Gateway SDK で自分で作成した拡張機能の 2 通りの方法で補完できます。

シスコの拡張機能は、別途配布されているモジュールで、追加のクレデンシャル タイプをサポートするように ACE XML Gateway を拡張します。次のタイプの拡張機能が存在します。

Netegrity トークン(Netegrity SiteMinder および TransactionMinder)

統合 Windows 認証 (Kerberos)


) シスコによって公開されている拡張機能の詳細については、シスコのサポート担当者に問い合せてください。拡張機能の作成については、Cisco ACE XML Gateway Developer Guideを参照してください。


1 つのオーセンティケータが IP アドレス、時刻、または WSS Password Digest のクレデンシャルに基づいて持つことができる条件は 1 つだけです。その他のクレデンシャル タイプについては、同一タイプに対して複数の条件を持つことができます。実際に、これによってユーザ名/パスワードの組み合わせなどの単一のクレデンシャルインスタンスを複数の方法でテストすることが可能になります(これは、1 つの要求に含まれるユーザ名/パスワードの複数の組み合わせのチェックをサポートするためのものではありません)。たとえば、1 つの条件では LDAP バインドでパスワードクレデンシャルをテストし、他の条件ではアクセス コントロール検証でパスワードをチェックするようなオーセンティケータを持つことができます。

IP アドレス条件

IP アドレスクレデンシャルは、要求元の IP アドレスに基づいてアクセスを制御することを可能にします。要求元が特定の IP アドレスを持っていなければならないように指定することもできれば、受け入れ可能なアドレス範囲内に入っていればよいように指定することもできます。IP アドレス要件をセットアップする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 クレデンシャル要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [IP Address] を選択し、[Add] をクリックします。

ステップ 4 クレデンシャル要件で受け付けられるようにするアドレスの範囲をテキスト フィールドに、ドットで区切った十進数形式で入力します。次に例を示します。

10.1.0.101 - 10.1.0.201

単一アドレスの場合は、両方のフィールドに同じ IP アドレスを入力します。

ステップ 5 連続していない範囲を追加するには、[Add a New IP Address Row] ボタンをクリックします。

ステップ 6 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。

新しいクレデンシャル要件がオーセンティケータのページの [Required Credentials] エリアに現れます。


 

SSL/TLS 証明書条件

SSL/TLS クレデンシャル要件では、ACE XML Gateway は、要求に入れて提出された X.509 クライアント証明書に基づいてユーザを認証します。

クライアント証明書は、複数通りの方法で検証できます。クライアント証明書のフィンガープリントをポリシーに格納されている証明書のフィンガープリントと比較すれば、証明書が一致する場合にそのクレデンシャルを受け付けるようにできます。証明書の発行元を検証すれば、それが信頼できる認証局であることを確認できます。また、証明書から得た値を使用して、LDAP ディレクトリからユーザ データを取得することもできます。次に挙げる値が使用できます。

サブジェクト DN

サブジェクト代替名

サブジェクト鍵識別子

証明書フィンガープリント

ポリシーは値に正規表現を適用してから LDAP クエリーに使用することもできるため、これらの値の一部分を使用することもできます。したがって、たとえば DN から CN を抽出することもできます。ユーザのレコードが見つかった場合、返されたデータをさらに評価して、権限付与の決定を下すことができます。

SSL 証明書の要件を指定する手順は、次のとおりです。


ステップ 1 コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインし、操作メニューの[Access Control Browser] リンクをクリックします。

ステップ 2 クレデンシャル要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューの [SSL/TLS Certificate] を選択し、[Add] をクリックします。

ステップ 4 [SSL/TLS Certificate] ページで、受信した SSL/TLS 証明書を検証する方法を[Verify Using] メニューから選択します。次のオプションが選択できます。

SSL 証明書フィンガープリント(詳細については、「 SSL 証明書フィンガープリントによる検証 」を参照してください)。

SSL 認証局(詳細については、「 SSL 認証局による検証 」を参照してください)。

証明書ベースの LDAP クエリー(詳細については、「 LDAP クエリーによる検証 」を参照してください)。

ステップ 5 証明書が存在する場合には証明書を検証するけれども、要求に証明書が含まれていることを要求したくはない場合には、オプション [Verify only when a client certificate is present (allow requests without client certificates)] をイネーブルにします。

この場合、要求が証明書を含んでいて、それが設定されている条件を満たさなかった場合にだけ、要求がブロックされます。

ステップ 6 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。

新しいクレデンシャル要件がオーセンティケータのページの [Required Credentials] エリアに現れます。


 

1 つのオーセンティケータに複数の証明書条件を追加することもできます。この場合、要求が受け付けられるには、その要求がすべての条件を満たしていなければなりません。このため、1 つの要求に含まれている単一の証明書について、フィンガープリント マッチで検証してから、たとえば認証局でも検証したりできます。

SSL 証明書フィンガープリントによる検証

受信要求に含まれている証明書は、そのフィンガープリントをすでにポリシーにロードされているユーザ証明書のフィンガープリントと比較することによって検証できます。フィンガープリントが一致すれば、要求が受け付けられます。

フィンガープリント比較が正しく機能するには、比較される証明書を発行した CA がポリシーの中で信頼できる CA として指定されている必要があります(SSL ネゴシエーション中、ACE XML Gateway はクライアントにどの CA を信頼しているかを示します。クライアントのタイプによっては、このヒントがないと証明書を送らないものもあります。つまり、CA が信頼できる CA としてリストされていないと証明書を発行しないクライアントもあります)。

ポリシーにアップロードされている証明書とクライアント証明書を比較させる手順は次のとおりです。


ステップ 1 [require a client certificate that is identical to this certificate] を選択します。

ステップ 2 比較する証明書を選択し、それがまだリソースとして識別されていない場合はそれをアップロードします。

証明書がまだアップロードされていない場合は、フィンガープリント比較を設定しようとしている証明書の発行元の CA 証明書をアップロードします。


 

SSL 認証局による検証

クライアント証明書を発行した認証局の ID に基づいて証明書を信頼するように選択できます。証明書を CA によって検証するには、CA 証明書が信頼できる CA 証明書としてポリシーにアップロードされていなければなりません。デフォルトでは、ACE XML Gateway はどの CA も信頼しないようにセットアップされています。信頼する CA の指定は、信頼できる機関リソースのページで行えます。詳細については、「認証局リソースのアップロード」を参照してください。

クライアント証明書が信頼できる CA によって署名されていることを要求する手順は次のとおりです。


ステップ 1 [require a client certificate that is signed by] を選択します。

ステップ 2 証明書がポリシー内で設定されているいずれかの認証局によって署名されていればよいのか、選択した CA によって署名されていないといけないのかを選択します。

ステップ 3 必要に応じて、証明書のその他の制約を指定します。次のオプションが選択できます。

[Also require that the client certificate subject's Distinguished Name matches]、クライアント証明書のサブジェクトの DN を指定した正規表現と比較します。

[Also require that the client certificate issuer's Distinguished Name matches]、クライアント証明書の発行元の DN を指定した正規表現と比較します。

[Also require that the client certificate subject's Distinguished Name exactly matches this certificate]、クライアント証明書のサブジェクトの DN と選択した証明書が一致することを要求します。


 

LDAP クエリーによる検証

ACE XML Gateway は、LDAP を SSL 証明書サブジェクトの検証メカニズムとしてサポートしています。この条件は、ディレクトリ内にユーザのレコードが存在するかどうかだけをチェックすることもできれば、ユーザのレコードが見つかった場合に追加チェックとしてユーザのプロパティも評価することもできます。

LDAP 証明書チェックは、それ自体では証明書を認証できるわけでもなければ、信頼性を検証できるわけでもないため、通常は証明書の CA をチェックするオーセンティケータ条件かフィンガープリント マッチと一緒に使用します。

また、このタイプの検証では、要求にクレデンシャルが含まれていることを要求することはせず、クレデンシャルが存在する場合にだけそれを検証するのにも使用できます。この点で、この検証は、複数の WSS UsernameToken 条件、複数の SAML 条件などを持ち、クレデンシャルを要求はしないけれども、クレデンシャルが存在すればそれを検証する複数クレデンシャルモードのオーセンティケータに似ています。

LDAP レコードは、証明書から得られる識別プロパティを使用して、証明書のサブジェクトと比較されます。これは、LDAP ディレクトリが、ユーザの公開鍵のフィンガープリント、サブジェクト代替名、サブジェクト鍵識別子などのユーザ証明書から得られる値をユーザ アトリビュートとして持っているということを意味します。もしくは、証明書のサブジェクト DN を使用し、ディレクトリ内の有効なユーザ レコードと一致するように正規表現ベースのテキスト置き換えを DN に適用することもできます。

LDAP で証明書を検証する一般的な手順は次のとおりです。

手順 1:使用する LDAP ディレクトリを指定します。

手順 2:LDAP ディレクトリ内でユーザ レコードを検索する際に使用する、証明書からの値を指定します。

手順 3:LDAP ディレクトリ内で実施するフィルタを指定します。クエリーは、ディレクトリ内のユーザ アカウントが有効かチェックするために、ユーザ レコードからのアクセス決定に使用できるデータを返すか、またはユーザ レコードをそのまま返す必要があります。

手順 4:フィルタによって返されたデータに適用した場合に有効なユーザの結果を返す正規表現を指定します。

クライアントの SSL 証明書を LDAP ディレクトリで検証する手順は、次のとおりです。手順の後に、設定値の例を示します。


ステップ 1 [Verify Using] メニューの [Certificate-based LDAP Query] を選択します。

ステップ 2 証明書が要求に含まれていた場合には証明書を検証するけれども、クレデンシャルが存在することを特に要求はしない場合は、オプション [Verify only when a client certificate is present] を選択します。この場合、クレデンシャルを持たない要求はこのオーセンティケータで受け付けられますが、クレデンシャルが含まれていた場合には、そのクレデンシャルがこのオーセンティケータで指定されたとおりに検証されなければなりません。

ステップ 3 [Server] メニューから、クレデンシャルの検証に使用する LDAP サーバを選択します。使用したいサーバがリストに表示されていない場合は、[New LDAP Server] をクリックして、LDAP ディレクトリへの接続を設定します。

ステップ 4 [Certificate Field] で、検証に使用するデータが入っているクライアント証明書プロパティを選択します。これが [%d] 変数にバインドされるデータになります。これは、ユーザまたはアプリケーションを識別するシステム変数です。

ステップ 5 LDAP フィルタで証明書フィールドの値が「そのまま」使用できない場合は(通常は、サブジェクト DN を使用する場合が該当します)、値を LDAP ディレクトリ内の比較対象データに一致する形式に変換する必要があります。[Apply regular expression substitution to the certificate field value] オプションを選択し、正規表現と置き換えストリングを入力することにより、この変換をイネーブルにします(ACE XML Gatewayがクエリーを実行する前にクレデンシャルの値を変更する必要がない場合は、正規表現オプションをディセーブルのままにしておいてかまいません)。

このオプションが選択されていると、選択したクレデンシャルプロパティに正規表現が適用され、得られたデータが %d 変数に値を格納するのに使用されます。

正規表現と一致したデータは、「 \1 」、「 \2 」(これは元の値から正規表現に一致した 1 つ目のデータと 2 つ目のデータ)などの形式で、バックスラッシュ変数として使用できます。結果は、LDAP データと比較できる形式の DN でなければなりません。

元の値に正規表現を適用する手順は次のとおりです。

a. [Apply regular expression substitution to the certificate field value] チェックボックスを選択します。

b. 使用する正規表現を [Regex] フィールドに入力します。この正規表現は、LDAP クエリーで使用するフィールドの部分に一致している必要があります。

c. [Replace With] フィールドで、固定テキストと逆参照変数を使用して、ソース比較値を作成します。例については、この手順の後に続く例を参照してください。

正規表現でプロパティ値に一致するデータが得られなかった場合、プロパティ値は変更されません。正規表現作成のトラブルシューティングを支援するために、イベント ログに正規表現比較の結果、一致して置き換えが発生したか、それとも一致するデータはなかったかが示されます。

ステップ 6 [User DN] フィールドと [Bind with Password] フィールドに、ACE XML Gateway がユーザを検証するために LDAP ディレクトリにログオンする際に使用するクレデンシャルを指定します。

これは、ディレクトリ内にあり、クエリー権限を持っている既知の良好なユーザ アカウントのユーザ DN とパスワードでなければなりません。ACE XML Gateway がこの用途に使用するための専用のユーザ アカウントをディレクトリ内に作成することを推奨します。

ステップ 7 [Base DN] フィールドで、クエリー フィルタを適用するディレクトリの場所を指定します。

ほとんどの場合、これは %d になります。この変数には、[Client Certificate Settings] で指定した値(多くの場合、[Regex] と [Replace With] の結果で処理した後の証明書のサブジェクト DN)が入ります。

ステップ 8 [Filter] に、ベース DN で実行する LDAP クエリーを入力します。

これには、ベース DN で識別されたレコードの下のレコードを入力できますが、ベース DN が評価されるユーザ レコードを識別する場合は、 {{{(objectClass=*)}}} などの単に結果を渡すだけのフィルタ(つまり、no-op フィルタ)でもかまいません。これは、ベース DN のレコード全体を返します。

ステップ 9 必要であれば、[Attributes] フィールドを使用して、フィルタで返される情報を特定の LDAP アトリビュートの値だけに減らします。これにより、結果を検証するために必要な [Match Regex] を簡単にすることができます。

たとえば、営業担当者の E メール アドレスだけを使用し、他のデータは一切使用しないようにするには、[Attributes] フィールドに「mail」と入力します。これで、クエリーによって返される各レコードについて、 mail アトリビュートのリストだけが返されます。

複数のアトリビュートを指定して、複数の値を取得することもできます。複数のアトリビュート名を指定する場合は、スペースで区切ります。

アトリビュートの結果は、発信要求のために生成される SAML クレデンシャルに格納するために使用できます(SAML 生成ページの [Include LDAP records, if available, as SAML Attribute Statements] というオプションでイネーブルにできます)。

ステップ 10 [Match Regex] フィールドに、アトリビュートが指定されていない場合に、アトリビュート結果に対して実行する正規表現を入力します。

この正規表現で、返されたユーザ レコードのグループ メンバシップなどのアトリビュートをテストできます。正規表現を適用して一致するものが得られたら、その認証/権限付与は成功したと見なされます。

ステップ 11 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

たとえば、certFingerprint というアトリビュートに各ユーザの証明書のフィンガープリントが入っている LDAP ディレクトリがあったとすると、次のように検証設定をセットアップできます。

[Certificate field] Certificate Fingerprint (SHA-1)

[Regular expression substitution] disabled

[Base DN] dc=cisco,dc=com

[Filter] (certFingerprint=%d)

使用される証明書フィールドの値は証明書のフィンガープリントで、それが %d 変数に格納されます。フィルタがこの値を certFingerprint に対してチェックします。ディレクトリ内の certFingerprint が %d と一致した場合、フィルタ条件が満たされ、この条件が満たされます。

サブジェクト DN を一致条件の値として使用する場合、ACE XML Gateway がどのように DN をレンダリングするのかを理解しておくことが大切です。ACE XML Gateway は、証明書を処理する際に、証明書のサブジェクト DN を表すストリングを作成します。

開始する前に、デバッグ レベルでのロギングをイネーブルにした ACE XML Gateway に、証明書を持つ要求を送信してください。証明書に入っている正規化された DN がイベント ログに記録されます。これが、正規表現の実行対象となる値です。たとえば、サンプル証明書、 beagle.cer からの証明書を含む要求には、次のような説明が入ったエントリが生成されます。

DN of client certificate subject is emailAddress=operations@beaglepartners.com,CN=Beagle Partners Inc.,OU=Operations,O=Beagle Partners Inc.,L=Hampton,ST=Virginia,C=US

これが、正規表現の実行対象となる値です。したがって、正規表現を設計する際にはこの DN フォーマットを念頭に置いておく必要があります。

たとえば、このソース サブジェクト DN を次のような値に変換したかったとします。

CN=Beagle Partners Inc.,OU=Operations,O=Beagle Partners Inc.,ST=Virginia

次のような正規表現が必要になります。

emailAddress=[^,]*,CN=([^,]*),OU=([^,]*), O=([^,]*),L=[^,],ST=([^,]*),.*

emailAddress は無視されます(正規表現がカッコで囲まれていないため)。この正規表現の次の手順として、CN= の後ろの値が変数 \1 に入り、OU= の後ろの値が \2 に入り、その後の値も同様になります。L 値は、emailAddress 同様、無視されます。

[Replace With] の値は、次のようになります。

CN=\1, OU=\2, O=\3, ST=\4

図 6-3 に、このサンプルの設定を示します。

図 6-3 正規表現の設定

 

HTTP(S) Basic 認証条件

オーセンティケータは、HTTP Basic 認証のクレデンシャルを評価するように設定できます。このタイプのクレデンシャルでは、ユーザ名/パスワードのクレデンシャルが、メッセージのヘッダーに入れて渡されます。

HTTP Basic 認証のクレデンシャルを要求する手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [HTTP(S) Basic Authentication] を選択し、[Add] をクリックします。

ステップ 4 クレデンシャルを検証する方法を [Verify Using] メニューから選択します。

詳細については、「パスワード ベースのクレデンシャルの検証」を参照してください。

ステップ 5 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。

新しいクレデンシャル要件がオーセンティケータのページの [Required Credentials] エリアに現れます。


 

WSS Username/Password トークン条件

WSS UsernameToken は、WS セキュリティ仕様「Web Services Security UsernameToken Profile 1.0」で定義される認証メカニズムです。このタイプのトークンは、例 6-1 のサンプル トークンに示すとおり、SOAP エンベロープの SOAP ヘッダー部分に現れます。

例 6-1 WSS UsernameToken クレデンシャル

...
<soap:Header
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password
Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
...

WSS Username クレデンシャルは、クレデンシャル メディエーションの発信元クレデンシャルとして取得できます。つまり、受信要求から得たユーザ名/パスワード値が、発信要求に入れる Basic 認証または SAML トークンの生成に使用できます。さらに、WSS Username 要素内のカスタム WSS Username アトリビュートはすべて、生成される SAML AttributeStatements 内のアトリビュートにマッピングできます。このオプションをイネーブルにするには、[System Management] > [Gateway Settings] ページの [Send extension attributes from WSS UsernameTokens as attributes in generated SAML AttributeStatements] というラベルの付いたマッピング オプションを設定します。

1 つの要求に複数の WSS UsernameToken を入れることができ、それぞれが要求の生成における参加メンバを表すことができます。たとえば、1 つの要求が、要求を生成したエンド ユーザ用に 1 つのクレデンシャルを持ち、使用されたアプリケーション用に別のクレデンシャルを持ったりできます。1 つの要求内の複数のクレデンシャルに条件を課すオーセンティケータを設定できます。

複数のクレデンシャルに条件を課すには、WSS UsernameToken オーセンティケータで複数クレデンシャルモードをイネーブルにします。この設定では、ACE XML Gateway がメッセージ内に存在することを要求するクレデンシャルの数を指定する必要があります。これが、チェックされてクレデンシャル生成のために使用できるクレデンシャルの数になります。要求にこの数を超えるクレデンシャルが含まれていた場合、余分なクレデンシャルは無視されます。

いったん複数クレデンシャルモードをイネーブルにしたら、WSS UsernameToken クレデンシャルに基づくその他の条件を追加できます。条件を 1 つしか指定しなかった場合、すべてのクレデンシャルがその条件を満たす必要があります。この場合、その条件には、おそらく複数のユーザを検証できる検証メカニズム(LDAP クエリーなど)を使用することになります。一方、条件を 2 つ指定した場合は、どちらか片方の条件だけを満たす 2 つのクレデンシャルを持つ要求が受け付けられます。つまり、要求が受け付けられるには、要求内のすべてのクレデンシャルが、少なくとも 1 つのオーセンティケータのすべての条件を満たさなければなりません。

複数クレデンシャルモードは、クレデンシャルが存在することを要求するわけではないことに注意してください。要求にクレデンシャルが含まれていなければ、その要求はオーセンティケータによって受け付けられます。これには、このタイプのオーセンティケータに関連付けられているサービスを一般からアクセス可能にするという効果があります。このモードは、クレデンシャルが存在すればクレデンシャルを処理して検証するけれども、クレデンシャルの最小要件を課すわけではないという場合にだけ使用してください。

また、このオーセンティケータが適用される仮想サービスは SOAP ヘッダー処理がイネーブルになっていなければならないことにも注意してください。

オーセンティケータの WSS UsernameToken 要件をセットアップする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 クレデンシャル要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [WSS Username/Password] を選択し、[Add] をクリックします。

ステップ 4 次の手順で、複数クレデンシャルの検証をイネーブルにします。

a. [configure multiple WSS UsernameToken mode] リンクをクリックします。

b. [Enable multiple WSS UsernameToken mode, verifying at most] オプションを選択し、メッセージに含まれていると期待されるトークンの数を [verifying at most] フィールドに入力します。

ACE XML Gateway は、ここに指定した数のトークンを処理します。メッセージにそれを超えるクレデンシャルが含まれている場合、それらは無視されます。このオプションをイネーブルにすると、メッセージごとに検証するトークンの数に 0 や負の値を指定した場合でも、ACE XML Gateway は常に少なくとも 1 つのクレデンシャルをチェックします。

c. [Multiple WSS UsernameToken Mode] ページの [Save Changes] をクリックします。

これで、WSS UsernameToken クレデンシャルに関する複数の条件をこのオーセンティケータに追加できます。

ステップ 5 オーセンティケータのページで、再び WSS UsernameToken 要件を追加します。

ステップ 6 [Verify using] メニューを使用して、ユーザ名とパスワードの値を検証する方法を指定します。

詳細については、「パスワード ベースのクレデンシャルの検証」を参照してください。

ステップ 7 [Save Changes] をクリックします。

WSS ユーザ名/パスワードクレデンシャルはメッセージのヘッダーに入れて渡されるため、このオーセンティケータに関連付けられるすべてのメッセージ ハンドラで SOAP ヘッダー処理をイネーブルにする必要があります。

ステップ 8 まだ SOAP ヘッダー処理がイネーブルになっていない場合は、仮想サービス ブラウザで、このオーセンティケータを使用するハンドラまたは仮想サービスをクリックします。

ステップ 9 このページの [Request Processing] エリアで、[SOAP Header Processing] の横の [edit] リンクをクリックします。

ステップ 10 [Process header elements for SOAP role] チェックボックスがまだイネーブルになっていない場合は、このチェックボックスをクリックします。

その他のヘッダー処理タスクを設定しない場合は、その他の設定はデフォルト値のままにしておいてかまいません。

ステップ 11 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

これで、WSS Username/Password クレデンシャルチェックがイネーブルになりました。ポリシーを導入して、ACE XML Gateway がこの変更内容を実施するようにします。

WSS Password Digest 条件

デフォルトでは、前述の WSS Username/Password クレデンシャルは、暗号化されていないメッセージ ヘッダー内に入れられています。ネットワークを通過する際のメッセージのセキュリティを確保するためにトランスポート レベルの暗号化が使用されたとしても、パスワードが送信先に到達した後は、パスワードは保護されません。

セキュリティを高めるために、WSS Password Digest の使用を通じてクレデンシャルを暗号化することができます。WSS Password Digest は、パスワード値を暗号化して、送信中だけでなくエンドポイントでもパスワードのセキュリティを確保します。


) WSS Password Digest は、パスワードの暗号化に加えて、要求間で一意でなければならない任意の値であるナンスの使用を通じて、攻撃の再送を防ぐという用途もあります。ただし、ナンス値は ACE XML Gateway には保持されないため、ナンスの一意性は求められません。また、ACE XML Gateway はダイジェストの失効のチェックを行わないことにも注意してください。


SOAP エンベロープのヘッダーでは、パスワード ダイジェストは次のような形で現れます。

例 6-2 WS セキュリティ パスワード ダイジェストクレデンシャル

...
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>jdoe</wsse:Username>
<wsse:Password>Ikky9DZH7lZ52JGDaZDys8ALbbM=</wsse:Password>
<wsse:Nonce>MQ==</wsse:Nonce>
<wsu:Created>2006-02-13T15:43:46Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
...

 

ヘッダー内の Password 要素と Nonce 要素に注目してください。WSセキュリティ仕様で示されているとおり、パスワード トークンは、連結され、Base64 でエンコードされたナンスとタイムスタンプとパスワードを結合して暗号化(SHA1)することにより生成されます。

このため、トークンを評価するために、ACE XML Gateway は、メッセージから取得した Password に Base64 エンコードを適用して、16 進数の結果を生成します。次に、 Nonce をデコードし、それをメッセージ内のタイムスタンプおよびパスワード(オーセンティケータの設定に保存されている)と結合します。その後、連結した結果に SHA1 暗号化を適用します。この 16 進数の結果が、デコードされたダイジェスト値と比較されます。それらが一致すれば、要求は有効と見なされます。

WSS Password Digest クレデンシャル要件を得るには、仮想サービスが SOAP ヘッダーを処理するように設定されていなければなりません。SOAP ヘッダー処理をイネーブルにする設定は、仮想サービスの 要求と応答の処理の設定にあります。

WSS Password Digest クレデンシャル要件をセットアップする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 クレデンシャル要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [WSS Password Digest] を選択し、[Add] をクリックします。

ステップ 4 受け付けられるユーザ名とパスワードの値を該当するフィールドに入力し、[Save Changes] をクリックします。

このパスワードは、エンコードされていないパスワード値、つまりクライアントがダイジェスト パスワードを生成するために使用するパスワード値でなければなりません。

ステップ 5 WSS ユーザ名/パスワードクレデンシャルはメッセージのヘッダーに入れて渡されるため、このオーセンティケータに関連付けられるハンドラの SOAP ヘッダー処理がイネーブルになっている必要があります。まだイネーブルになっていない場合は、次の手順でヘッダー処理をイネーブルにします。

a. 仮想サービス ブラウザで、このオーセンティケータを使用するハンドラまたは仮想サービスの名前をクリックします。サービス ハンドラのメッセージ仕様設定が表示されます。

b. このページの [Request Processing] エリアで、[SOAP Header Processing] の横の [edit] リンクをクリックします。

c. [Process header elements for SOAP role] の横のチェックボックスがまだ選択されていない場合は、このチェックボックスをクリックします。

その他に必要なヘッダー処理タスクがない場合は、残りの設定はデフォルト値のままにしておいてかまいません。

ステップ 6 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

これで、WSS Password Digest クレデンシャルチェックがイネーブルになりました。この変更内容を ACE XML Gateway に反映させるために、ポリシーを導入してください。

SAML トークン条件

SAML(Security Assertion Markup Language)は、セキュリティ情報を交換するための XML ベースのプロトコルです。SAML は、組織の境界を越えてシングル サインオン機能を提供することを目的としています。SAML クレデンシャルは、メッセージの WS セキュリティ ヘッダー ブロック内でトークン要素の形式を取ります。

ACE XML Gateway は、SAML クレデンシャルについて、リレー パーティまたはアサート パーティとして機能できます。つまり、SAML アサーションに基づいてオーセンティケータ条件を設定することもできれば、送信メッセージにアサーションを追加することもできます。ACE XML Gateway は、SAML バージョン 1.0、1.1、および 2.0 をサポートします。

SAML アサーションが ACE XML Gateway によって信頼されるようにするには、XML 署名によってか、あるいはユーザと Gateway の間の接続の SSL 暗号化を通じて、その整合性が確保されていなければなりません。このため、SSL 要件には、仮想サービスが SSL でセキュリティ確保されたポートを使用するように設定されている必要があります。

その他のタイプのクレデンシャル要件と同様に、SAML 要件もオーセンティケータ内で指定します。受信要求に単一の SAML トークンまたは複数のトークンを要求するようにオーセンティケータをセットアップできます。デフォルトでは、SAML トークンは ACE XML Gateway によって消費されます。つまり、検証の後、要求から取り外されます。パススルーを設定するには、サービス インターフェイス定義のバックエンド サービス認証を指定します。

SAML 要件は、SAML アサーション内に次の要素のうちの少なくとも 1 つを要求しなければなりません。

認証文

権限付与決定文

アトリビュート文

オーセンティケータは、受け付けられるために要素が持っていなければならないさまざまなプロパティを指定できます。たとえば、アサーションが、サブジェクトがパスワードで認証されたことを示す認証文を持っていることを要求したりできます。

SAML アサーションのタイムスタンプ条件は、ACE XML Gateway によって自動的に検証されます。たとえば、ACE XML Gateway の内部システム クロックと食い違っていないかを調べるために、 NotBefore 条件と NotOnOrAfter 条件がチェックされ、無効であれば、アサーションは拒否されます。


) ACE XML Gateway は、同じアサーションの検証によってパフォーマンスの負荷が発生することを避けるために、SAML アサーションの検証結果をキャッシュに格納できます。SAML アサーション キャッシングは、[System Management] > Gateway [Settings] ページからイネーブルにします。[SAML Assertion Caching] の設定が、ページの下部に表示されます。


SAML トークン要件を設定する手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 SAML クレデンシャル要件の追加先とするオーセンティケータをクリックするか、または「オーセンティケータと権限付与グループでの作業」の手順に従って新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [SAML Token] を選択し、[Add] をクリックします。

ステップ 4 [Verify Using] メニューで、認証するクレデンシャルの SAML バージョンを次の中から選択します。

SAML 1.0

SAML 1.1

SAML 2.0

この選択により、SAML バージョン間の違いを反映して、このページで設定できるオプションが変わります。オプションを使用して、このオーセンティケータが要求するアサーションの特性を指定します。

ステップ 5 SAML アサーションは、1 つの要求に複数入れることができます。この条件を要求内の指定した数のクレデンシャルに適用するのか、それともすべてのクレデンシャルに適用するのかを次のオプションから選択します。

[At least] には、要求内でこの条件を満たさなければならないクレデンシャルの最低数を指定できます。要求が持つ有効なアサーションの数が指定した数より少ない場合、その要求はブロックされます。

[All] には、要求内のすべてのアサーションがこの条件を満たさなければなりません。

[all] を選択した場合、要求内のクレデンシャルの最低数は要求されなくなることに注意してください。要求が SAML アサーションを 1 つも含んでいなかった場合、その要求はこのオーセンティケータで受け付けられます。これには、このタイプのオーセンティケータに関連付けられているサービスを一般からアクセス可能にするという効果があります。このモードは、クレデンシャルが存在すればクレデンシャルを処理して検証するけれども、クレデンシャルの最小要件を課すわけではないという場合にだけ使用してください。

ステップ 6 その SAML アサーションが受け付けられるために適切である場合は、次のようにして [Audience] 条件を指定します。

a. [Require an Audience Condition that matches any one of the following] というラベルのチェックボックスを選択します。

b. [Require an Audience Condition] チェックボックスの下にある入力フィールドに、このアサーションに必要なオーディエンス URI を入力します。

c. 必要に応じて、2 つ目以降の Audience 条件を追加します。

1 つのメッセージが複数の Audience 要素を含むことができ、そのいずれもオーセンティケータで要求することができます。アサーションに、オーセンティケータによって要求されない Audience 要素が含まれている場合、その要素は無視されます。

ステップ 7 アサーションの Subject は、そのアサーションが証明するユーザ、アプリケーション、またはその他のパーティを表します。必要であれば、次の手順で NameIdentifier 要件を設定することにより、 Subject の要件を指定できます。

a. [NameIdentifier is] ボタンをクリックします。

b. [NameIdentifier is] の横にあるフィールドに、オーセンティケータが要求するサブジェクトの NameIdentifier 値を入力します。

c. 必要であれば、[with NameQualifier] チェックボックスを選択し、テキスト フィールドに NameQualifier の値を入力することにより、 NameIdentifier 値に管理ドメインまたはセキュリティ ドメインの制限を課します。

NameIdentifier には、管理ドメインまたはセキュリティ ドメインを指定します。これは、衝突を避けるために、異なるユーザ ストアからの名前を連結する手段を提供します。

d. [with Format] チェックボックスを選択し、[with Format] メニューからオプションを選択することによって、 NameIdentifier 値の形式を指定します。オプションは SAML のバージョンごとに変わりますが、基本的に次のオプションがあります。

[#emailAddress] を選択すると、 NameIdentifier 値が、IETF RFC 2822 の「addr-spec」で規定されるとおり、次のような local-part@domain 形式の E メール アドレスになっていることが要求されます。

<NameIdentifier Format="urn:oasis:names:tc:
SAML:1.0:assertion#emailAddress">
jdoe@example.com
</NameIdentifier>

[#X509SubjectName] を選択すると、 NameIdentifier が X.509 Subject DN の形式になっていることが要求されます。

[#WindowsDomainQualifiedName] を選択すると、NameIdentifier 値が Microsoft Windows® プラットフォームのドメイン修飾ユーザ名の形式 DomainName\UserName になっていることが要求されます。必要であれば、ドメイン名と区切り文字「\」を省略できるようにできます。

NameIdentifier 要素を無視するには、[Ignore the NameIdentifier value] ボタンをクリックします。

ステップ 8 [Subject Confirmation] の設定は、ACE XML Gateway がアサーションの整合性をどのようにして評価するかを制御します。 Subject を確認する方法を設定する手順は次のとおりです。

受信アサーションで受け付けられる確認方法を次の中から選択します。

[Sender Vouches] を選択すると、「sender-vouches」の確認方法が許可されます。sender-vouches の確認方法は、リレー パーティ(この場合、ACE XML Gateway)が送信元と既存の信頼関係を持っていることか、またはバックエンド サービスが sender-vouches によって示されるより厳しいレベルの要件は要求しないことを示します。

[Holder-of-key] は、サブジェクトが holder-of-key の確認方法で認証できることを意味します。この確認方法では、鍵情報が SubjectConfirmationData 要素に入れて渡されます。ACE XML Gateway は、参照される鍵をオーセンティケータの SSL/TLS 証明書要件と照らし合わせて検証します。

[Artifact] を選択すると、Gatewayが、送信元の身元を確認するために使用できる SAML アーティファクトをメッセージから取り出すようになります。

[Bearer](SAML 1.1 用)は、アサーションのサブジェクトが、SubjectConfirmationData 要素で指定されている確認に関する任意のオプションの制約に対して、自分でサブジェクトを確認できるように指定します。

この方法の URI プレフィクスは、次のとおりです。

urn:oasis:names:tc:SAML:1.0:cm は、sender-vouches、holder-of-key、artifact、および bearer に適用されます。

urn:oasis:names:tc:SAML:2.0:cm は、sender-vouches、holder-of-key、artifact、および bearer に適用されます。

たとえば、受信メッセージは次のように holder-of-key を示します。

<SubjectConfirmation
Method="urn:oasis:names:
tc:SAML:1.0:cm:holder-of-key">
<SubjectConfirmationData>
...
</SubjectConfirmationData>
</SubjectConfirmation Method>

メッセージの整合性を確保する方法を指定するには、[Integrity Protection] メニューから次のいずれかの項目を選択します。

[SSL (HTTPS)] を選択すると、要求の作成に使用される接続が SSL でセキュリティ確保されていなければなりません。


) この確認方法を選択した場合は、セキュリティを向上させるために、SSL/TLS クレデンシャルをテストするようにオーセンティケータを設定してください(「SSL/TLS 証明書条件」を参照)。


[XML Signature] を選択すると、オーセンティケータがメッセージの署名付き要素を確認するために使用できる公開鍵をメッセージが提供しなければなりません。

ステップ 9 アサーションが持たなければならないサブジェクト文を [Subject Statement] で選択します。少なくとも 1 つのサブジェクト文を要求しなければなりません。

[Require an Authentication Statement]。任意のタイプの認証文、または特定の認証方法を示す認証文を要求するには、このオプションを選択します。

認証方法を指定した場合は、アサーションがその認証方法を反映している必要があります。そうなっていないと、メッセージが拒否されます。次の方法が選択可能です。

[Password] の方法は、サブジェクトの認証にパスワードが使用されたことを示します。その他の認証方法が使用された場合、オーセンティケータはメッセージを拒否します。

[Kerberos] は、サブジェクトの認証に Kerberos が使用されていることを要求します。

[Secure Remote Password] は、サブジェクトの認証に Secure Remote Password プロトコルが使用されていることを要求します(RFC 2945 を参照してください)。

[Hardware Token] は、サブジェクトの認証のハードウェア トークンが使用されていることを要求します。

[SSL/TLS Certificate] は、証明書ベースのクライアント認証の実行に SSL プロトコルか TLS プロトコルのいずれかが使用されていることを要求します。

[X.509 Public Key] は、サブジェクトの認証に X.509 公開鍵に基づいたメカニズムが使用されていることを要求します。

[PGP Public Key] は、サブジェクトの認証に PGP Web の信頼による鍵認証に基づいたメカニズムが使用されていることを要求します。

[SPKI Public Key] は、サブジェクトの認証に SPKI 公開鍵インフラストラクチャに基づいたメカニズムが使用されていることを要求します。

[XKMS Public Key] は、サブジェクトの認証に XKMS 信頼サービスに基づいたメカニズムが使用されていることを要求します。

[XML Digital Signature] は、サブジェクトの認証に XML ダイジェスト署名が使用されていることを要求します。

[Unspecified] は、アサーションが確認方法として「unspecified」を示す可能性がある場合に使用できます。

[Require an Authorization Decision Statement that permits access to] オプションをクリックして、指定したリソースへのアクセスを許可する権限付与決定文に基づいた文を指定します。

アサーションにアトリビュート文が入っていることを要求するには、[Require Attribute Statement(s)] チェックボックスをクリックし、次のフィールドを使用してアトリビュート要件を指定します。

[Attribute Name] には、要求するアトリビュートの名前を指定します。

[Attribute Namespace] には、 AttributeName 要素を解釈するための名前空間を指定します。

[Attribute Value] フィールドには、アトリビュートのテキスト値を指定します。

ステップ 10 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

いったんポリシーを導入したら、オーセンティケータが、指定したアトリビュート文の条件をすべて満たしていないメッセージは拒否するようになります。

XPath Password 条件

XPath Password クレデンシャルは、ACE XML Gateway での数タイプあるパスワード ベースの資格条件のうちの 1 つです。このクレデンシャルは、「パスワード ベースのクレデンシャルの検証」で説明したメカニズムのうちの 1 つによって検証されます。

XPath パスワードクレデンシャル要件は、メッセージ内の XPath で指定される場所の 2 つの値をテストします。メディエーションと ID 追跡のために、この 2 つの値がユーザ名およびパスワードの値として解釈されます。


) XPath パスワード チェックは、暗号化されている受信メッセージには機能しません。このタイプのクレデンシャルチェックはメッセージが復号される前に発生するため、暗号化されたメッセージではこの要件は満たされません。


XPath ユーザ名/パスワード認証要件をセットアップする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス条件を設定するオーセンティケータをクリックするか、新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [XPath Password] を選択し、[Add] をクリックします。

ステップ 4 XPath 式でメッセージの本文内のクレデンシャルが現れると期待される場所を入力します。

たとえば、受信 XML メッセージの次の場所にユーザ名が入っているとします。

//Envelope/Body/retrieveQuote/user

次のような XPath 式で抽出できます。

//*[local-name()='Envelope']/*[local-name()= 'Body']/*[local-name()='retrieveQuote']/ *[local-name()='user']/text()


local-name() 関数は、各要素名を名前空間で修飾する必要性を回避するための標準の XPath 関数です。


ステップ 5 ACE XML Gateway は、XPath で指定された場所からユーザ名とパスワードの値を抽出します。[Verify Using] メニューから適切な方法を選択することにより、値を検証する方法を設定します。

ステップ 6 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

新しいクレデンシャル要件がオーセンティケータのページの [Required Credentials] エリアに現れます。

セキュリティ トークン条件

セキュリティ トークンは、HTTP ヘッダー、GET 引数または POST 引数のいずれかから得られるシングル パートの値か、またはメッセージの XPath で指定される部分です。トークンの値を元に認証を設定できます。要件では、正規表現によってか、または外部 SOAP サービスによってトークンを検証できます。


) セキュリティ トークン チェックは、暗号化されている受信メッセージには機能しません。このタイプのクレデンシャルチェックはメッセージが復号される前に発生するため、暗号化されたメッセージではこの要件は満たされません。


SOAP サービスによるトークンの検証では、ACE XML Gateway は、SOAP 要求の形式でトークンをサービスに送信し、その応答として返されるアクセス決定を待ちます。応答の SOAP 本文要素の下の最初の要素の内容として「Permit」(大文字と小文字は区別されます)という文字が現れたら、ユーザは、この条件で受け付けられたものと見なされます。応答のこの場所に「Permit」が現れない場合は、要求は拒否されるものと見なされます。

ACE XML Gateway は、要件の設定に基づいてアクセス決定要求を生成します。要求には、要求されるサービスなど、ユーザ要求に関する情報を含めることができます。これは、決定を伝えるために使用できます。

サンプル要求を次に示します。

例 6-3 サンプル SOAP 認証要求(見やすいように改行が加えてあります)

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body soap:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<authService>
<token xsi:type="xsd:string">[tokenvalue]</token>
<path xsi:type="xsd:string">/service/order.asmx</path>
<action xsi:type="xsd:string">
"http://oakinsurance.com/order/retrieveQuote"
</action>
<method xsi:type="xsd:string">retrieveQuote</method>
<methodns xsi:type="xsd:string">
http://oakinsurance.com/order/
</methodns>
</authService>
</soap:Body>
</soap:Envelope>
 

サンプル要求の中の各要素は次のとおりです。

authService は、オーセンティケータの条件設定の中の [Method] の値です。

token は、ユーザ要求の XPath(または HTTP ヘッダー)で抽出される値です。

path は、ACE XML Gateway 上でのユーザにより要求されたサービスのパスです。

action は、元のユーザ要求に入っていた SOAPAction です。

method は、元のユーザ要求の中で要求されたサービス方式です。

methoddns は、元の要求に入っていた方式の名前空間です。

要求を受け取ったサービスは、これらの値を必要な任意の方法で使用して、アクセス決定を下すことができます。ACE XML Gateway の視点からすると、期待される形式での応答がそのまま返さなければなりません。

応答に推奨される構造は、ACE XML Managerのセキュリティ設定ページからダウンロードして入手できる Web Services Description Language(WSDL)ファイルに記述されています。

サービスからGatewayへのポジティブな応答には、SOAP 本文の下の最初の要素の最初のサブ要素の内容として「Permit」の文字が含まれていなければなりません。これが含まれていないと、ACE XML Gateway は、ユーザ要求をブロックします。

たとえば、ACE XML Gateway は、次のような応答をポジティブ応答と解釈します。

例 6-4 アクセスが許可される例

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<AuthenticationService>
<response>Permit</response>
</AuthenticationService>
</soap:Body>
</soap:Envelope>

この場合、 response という名前の要素の中に「Permit」が現れています。ただし、ACE XML Gateway にとって要素名は重要ではありません。決定要素は親要素なので、この名前は何でもかまいません。重要なのは、ポジティブ応答の SOAP Body サブ要素の下の最初の要素の内容に「Permit」が現れることです。その他のテキストがあると、ユーザの要求がブロックされることになります。

ACE XML Gateway は、次の XPath を持つ応答に決定を入れます。

/*[local-name()='Envelope']/*[local-name()='Body']/*[1]/*[1]/text()

次の例もポジティブな決定を示しています。

例 6-5 myAuthService により許可されたアクセス

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<myAuthService>
<decision>Permit</decision>
</myAuthService>
</soap:Body>
</soap:Envelope>
 

セキュリティ トークン要件を設定する手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス条件を設定するオーセンティケータをクリックするか、新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [Security Token] を選択し、[Add] をクリックします。

ステップ 4 次のオプションの中からトークンのソースを指定します。

HTTP 引数。GET 要求のクエリー ストリングまたは POST の本文から取り出された HTTP 引数値(内容は、タイプ application/x-www-form-urlencoded です)。

HTTP ヘッダー。メッセージ内の HTTP ヘッダーの値。

XPath 式。XPath 式で識別されるメッセージからの任意の内容。

ステップ 5 トークンを検証する方法に次のいずれかを選択します。

正規表現

外部サービス

ステップ 6 外部サービスを使用する場合は、次の手順を実行します。

a. [Verify Using] メニューから [SOAP Callout] を選択します。

b. 権限付与サービスの値を入力します。

[Service Host] には、権限付与サービスをホストしているマシンのホスト名を指定します。

[Port] には、サービス ホストが権限付与要求をリスンしているポートを指定します。

[Path] には、ホスト上での権限付与サービスのパスを指定します。

[SOAPAction] には、要求の中で使用される SOAPAction 値を指定します。

c. 権限付与を実行するメソッドの名前と、メソッドの名前空間を入力します。

d. 必要であれば、SOAP 引数 namespace-qualified(Document スタイルのサービス用)を持たせ、応答キャッシングをイネーブルにします。

ステップ 7 [Save Changes] をクリックします。新しいクレデンシャル要件がオーセンティケータのページの [Required Credentials] エリアに現れます。


 

必要に応じて、権限付与サービスのために生成された WSDL を持つこともできます。これには、[Show WSDL for this Authorization Service] ボタンをクリックします。IDE 内でこの WSDL からサービス コードを生成することにより、権限付与サービスのための枠組みとなるコードをすばやく生成できます。

Time-of-Day 条件

対象となるユーザ層の業務時間中にだけサービスを利用可能にすることにより、バックエンド システムのセキュリティに貢献できます。ACE XML Gateway システムでは、1 日の時間帯に基づいたオーセンティケータ要件を指定することができます。この要求の評価には、内部システム クロックが使用されます。許可された時間帯から外れた要求は、オーセンティケータによって拒否されます。

時間に基づいたチェックをセットアップする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス条件を設定するオーセンティケータをクリックするか、新しいオーセンティケータを作成します。

ステップ 3 [Add Credential] メニューから [Time-of-Day] を選択し、[Add] をクリックします。

ステップ 4 [Time-of-Day] 編集ページで、[accept the message only during] ボタンをクリックします。

ステップ 5 [From] フィールドと [To] フィールドに、オーセンティケータがメッセージを受け付ける時間帯をグリニッジ標準時(GMT)で入力します。たとえ Manager Web コンソールがその他の時間帯を使用して時刻を表示するように設定されている場合でも、この範囲は GMT にしなければなりません。

この値は、NN:NN という形式になっている必要があります。NN は 1 より大きく 12 より小さい整数です。

ステップ 6 [From] フィールドの横のメニューから、[AM] または [PM] を選択します。

ステップ 7 [To] フィールドに、メッセージの受け付けを停止する時刻を入力します。

この値は、NN:NN という形式になっている必要があります。NN は 1 より大きく 12 より小さい整数です。たとえ Manager Web コンソールがその他の時間帯で時刻を表示している場合でも、この範囲はグリニッジ標準時(GMT)にしなければなりません。

ステップ 8 [To] フィールドの横のプルダウン メニューから、[AM] または [PM] を選択します。

ステップ 9 メッセージを受け付ける曜日を指定するには、メッセージを受け付ける曜日を表す 1 つまたは複数のチェックボックスをクリックします。

ステップ 10 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

[Time-of-day] クレデンシャル条件が [Authenticator] の設定に現れます。変更内容を導入して、ACE XML Gateway に反映させます。

パスワード ベースのクレデンシャルの検証

ACE XML Gateway 内の複数のタイプのクレデンシャルが、パスワードに基づいています。これには、HTTP Basic 認証、WSS Username/Password、XPath Password が含まれます。さらに、ACE XML Gateway SDK を通じて作成されたカスタムクレデンシャルにより、汎用的なユーザ名/パスワードクレデンシャル タイプを拡張することもできます。

パスワード ベースのクレデンシャルは、次の検証メカニズムで検証できます。

ポリシーに格納されている固定値

パスワード ファイル

Active Directory ® サーバ

LDAP サーバ

固定値とは、ユーザのクレデンシャルが一致していなければならないユーザ名/パスワードの組み合わせで、オーセンティケータ内で明示的に設定されたものです。パスワード ファイルとは、受け付けられるユーザ名とパスワードの組み合わせが入った Apache 形式の htpasswd ファイルです。クレデンシャルインターフェイスで使用できるようにするには、まずファイルを ACE XML Manager 内にリソースとしてアップロードしておく必要があります。ファイルをアップロードするには、操作メニューの [Password Files] リンクをクリックし、そこから ACE XML Manager インターフェイスに表示される指示に従ってパスワード ファイルを追加します。

Active Directory と LDAP での検証では、複数の検証モードが使用可能です。これらのモードとそれをセットアップする手順については、以降の説明を参照してください。

Active Directory LDAP クエリーでのクレデンシャルの検証

ACE XML Gateway は、Active Directory ディレクトリ サービスを、サービス要求に入れて渡されたパスワード ベースのクレデンシャルの検証メカニズムとしてサポートしています。ACE XML Gateway は、Active Directory でのユーザクレデンシャルの検証を次の 2 通りの方法で行えます。

ACE XML Gateway は、Active Directory サーバと、要求に入れて渡されたユーザの DN およびパスワードのバインドを試みることができます。成功は、クレデンシャルがディレクトリ アカウントと一致したことを示します。

バインド試行に加えて、ACE XML Gateway は、ユーザの memberOf アトリビュートが特定の値になっているかチェックすることもできます。

検証が機能するには、サービス要求に入れて渡されたユーザ名が Active Directory ユーザ アカウントの DN か、その他のアトリビュート( sAMAccountName アトリビュート、 mail アトリビュートなど)を通じて DN にマッピングできる値のいずれかでなければなりません。

実際には、サービス要求に入っているユーザ名が Active Directory サーバ内のアカウントの DN( cn=Joe User,cn=Users,dc=Cisco,dc=Com など)とまったく同じということはまずありません。しかし、ユーザ名が sAMAccountName などのその他のユーザ アトリビュートにマッピングされていれば、ACE XML Gateway がバインドを試みる前に DN を取得することを可能にするマッピング クエリーを設定できます。

マッピング クエリーを発行するために、ACE XML Gateway は、まず Active Directory サーバを既知の有効なアカウントとバインドします。ACE XML Gateway のための専用アカウントを Active Directory サーバ内に作成することを推奨します。

図 6-4 に、検証がこの 3 段階のプロセスで設定されている場合の ACE XML Gateway と Active Directory サーバの間の相互作用を示します。ここに示したシーケンスでは、検証が成功しています。マッピング クエリーのアトリビュートが一致できないなど、いずれかのポイントで失敗すると、当然、プロセスは短縮されます。

図 6-4 Active Directory 検証シーケンス

 

Active Directory LDAP クエリー検証の設定

Active Directory サーバでのユーザ名/パスワードクレデンシャル検証を設定する手順は次のとおりです。


ステップ 1 いずれか 1 つのパスワード情報タイプ(HTTP Basic 認証、WSS Username、または XPath パスワード)のためのオーセンティケータ条件をセットアップした後、[Verify Using] メニューから [Active Directory Query] オプションを選択します。

ステップ 2 ユーザのクレデンシャルを検証する Active Directory サーバを [Server] メニューから選択します。

使用したいディレクトリが [Server] メニューに表示されていれば、リストからそれを選択します。それが表示されていない場合は、[New LDAP Server] ボタンをクリックして、Active Directory サーバとの接続を設定します。

ステップ 3 設定できる最もシンプルな検証モードでは、ACE XML Gateway は、要求に入れて提供されたユーザ名とパスワードでのログインを単純に試みます。

この方法を使用するには、[No lookup; use credential username as the full user DN] というラベルの付いたオプションを選択します。サービス要求に入れて渡されるユーザ名は、Active Directory サーバとのバインドに使用できる完全な DN でなければなりません。

ステップ 4 サービス要求に入れて手渡されたユーザ名がディレクトリ内の DN と直接には対応しないけれども、ユーザのその他のアトリビュートに一致する場合は、ユーザ名マッピング クエリーを使用してユーザの DN を取得し、それをバインド試行に使用することができます。

マッピング クエリーをセットアップする手順は次のとおりです。

a. [Map credential username to] オプションを選択します。

b. メニューから、値が有効なユーザのユーザ名と一致するアトリビュートを選択します。最も考えられるアトリビュートオプションは定義済みのもので、 mail sAMAccountName 、および userPrincipalName があります。ただし、[other LDAP attribute] を選択すれば、必要な任意のアトリビュート名を指定できます。

ACE XML Gateway は、この選択に基づいて、 (sAMAccountName=juser) などのフィルタを作成します。

c. ACE XML Gateway がクエリーを実行するためのディレクトリとのバインドに使用する有効なクレデンシャルを指定します。[Bind] メニューから、次のいずれかを選択します。

[anonymously] ディレクトリが匿名のバインドを受け付ける場合で、匿名アカウントがユーザ レコードの検索を行う特権を与えられて設定されている場合に選択します。

[with DN specified] ACE XML Gateway に指定したアカウントとバインドさせる場合に選択します。この場合、[Bind with DN] フィールドに有効な個別の名前を入力し、そのパスワードも入力します。


) ACE XML Gateway がこの用途に使用するための専用のアカウントをディレクトリ内に作成することを推奨します。アカウントを作成している場合は、ACE XML Gateway のアカウントの DN とパスワードを入力します。


d. [Base DN] フィールドに、クエリーで問い合せるユーザ アカウントが入っている「フォルダ」を入力します。たとえば、 cn=Users,dc=Cisco,dc=Com のような値になります。

ステップ 5 必要に応じて、認証されたユーザの memberOf アトリビュートが特定の値であることをチェックして、さらに条件を課すこともできます。

これを行うには、[Verify that user is a member of a group with name] というラベルのチェックボックスをクリックし、オーセンティケータがユーザに条件として課す memberOf アトリビュートの値を入力します。

ステップ 6 [Error Handling] オプションは、クライアントが LDAP システムから取得した拡張エラー コードを取得することを可能にします。このオプションは、次のタイプのオーセンティケータに導入されています。

•Active Directory LDAP Query

•LDAP Bind Success

•LDAP Query

LDAP エラー コードを応答に追加するには、例外マッピングを設定しなければなりません。「認証の失敗または権限付与の失敗」のための [Message Body] フィールドに [%s] を追加します。詳細については、「グローバル例外の設定」を参照してください。

ステップ 7 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

クレデンシャル条件がオーセンティケータの設定に現れます。変更内容を導入して、ACE XML Gateway に反映させます。

LDAP でのクレデンシャルの検証

パスワード ベースのクレデンシャルを LDAP サーバで検証するための手順は、「Active Directory LDAP クエリーでのクレデンシャルの検証」 で説明した Active Directory での検証の手順とよく似ています。

Active Directory での検証と同様、ACE XML Gateway は、LDAP 用のクレデンシャルを次のような複数の方法を通じて検証できます。

最もシンプルな場合、ACE XML Gateway は、要求に入っていたユーザ名とパスワードで LDAP サーバとバインドしようとします。バインド試行が成功したら、要求はこの条件を満たしたと見なされます。

バインド試行があってもなくても、ACE XML Gateway は、特定のユーザ アトリビュートの値をディレクトリにクエリーで問い合せることができます。

バインド試行では、ACE XML Gateway は、あらかじめ管理者が指定していた DN をユーザ名として提出することもできれば、セットアップ クエリーを通じて取得した DN を提出することもできます。セットアップ クエリーは、サービス要求から取得したユーザ ID(jdoe2 など)を LDAP サーバで使用されている識別名(DN)(cn=Jane Doe, cn=Users, dc=Cisco, dc=com など)にマッピングします。

LDAP バインド パスワード検証の使用

LDAP での最もシンプルなパスワード検証モードでは、ACE XML Gateway は、要求に入れて提供されたユーザの DN およびパスワードを使用して、単純にログインを試みます。ほとんどの場合、要求に入れて渡されたユーザ名は、LDAP ディレクトリ内のユーザ DN の形式と直接には一致しません。このため、要求に入れて渡されたユーザ名を何らかの方法で DN にマッピングする必要があります。

これは、次のような複数の方法で行えます。

ユーザ名がその他のユーザ アトリビュート( userPrincipalName など)に対応する場合は、ACE XML Gateway に、アトリビュートを検索して、一致したレコードの完全な LDAP 名を返す(見つかった場合)セットアップ クエリーを発行することによって DN を取得させることができます。

要求に入っていたユーザ名の値が DN の一部分(Common Name(cn)など)に確実に一致する場合は、「パラメータ化された」DN を指定することにより、セットアップ クエリーの使用を避けることができます。

要求から得られたユーザ名の値を、次のように代入変数として DN に追加できます。

cn=%u,cn=Users,dc=Cisco,dc=Com

実行時には、 %u が要求から得たユーザ名に置き換えられます。

次の手順では、LDAP バインド検証をセットアップ クエリーで設定する方法と、セットアップ クエリーなしで設定する方法を示します。


ステップ 1 パスワードクレデンシャル タイプ(HTTP Basic 認証、WSS Username など)のオーセンティケータ条件では、[Verify Using] メニューから [LDAP Bind Success] を選択します。

[Server]、[Setup Query]、および [Bind] の設定が現れます。

ステップ 2 使用する LDAP サーバへの接続がすでのポリシー内で定義されている場合は、それを [Server] メニューから選択します。まだ定義されていない場合は、[New LDAP Server] ボタンをクリックして、LDAP サーバとの接続を設定します。

ステップ 3 ACE XML Gateway に、セットアップ クエリーを使用させ、バインド試行を行うための DN を取得させるために、次の手順を実行します。

a. [Perform setup query, storing result DN in substitution variable %d] というラベルのチェックボックスをクリックします。

b. ACE XML Gateway がセットアップ クエリーを実行するためにディレクトリとバインドするときの方法を、[Bind] メニューから選択して指定します。

[anonymously] ディレクトリが透明アクセスをサポートしており、そのアカウントがユーザ レコードを検索する特権を持っている場合に選択します。

[with DN specified] ACE XML Gateway に指定したアカウントとバインドさせる場合に選択します。[User DN] フィールドに有効な識別名を入力し、そのパスワードも入力します。


) ACE XML Gateway がこの用途に使用するための専用のアカウントをディレクトリ内に作成することを推奨します。アカウントを作成している場合は、ACE XML Gateway のアカウントの DN とパスワードを入力します。


c. [Base DN] フィールドに、クエリーで問い合せるユーザ アカウントが入っている「フォルダ」を入力します。たとえば、 cn=Users,dc=Cisco,dc=Com のような値になります。

複数のツリーとフォレストを持つ非常に複雑な Active Directory インスタンスがある場合、LDAP ブラウザを使用して、使用できる正しい DN を確認しなければならないこともあります。

d. [Filter] フィールドで、サービス要求を発行したユーザのアカウントを一致させる目的で特定のユーザ プロパティをテストする LDAP フィルタ式を指定します。このマッピングは、要求から得たユーザ名の値が格納されている %u 変数によって補助されます。次に例を示します。

(|(cn=%u)(uid=%u))

指定したベース DN の下の cn プロパティまたは uid プロパティの値が要求から取得したユーザ名と一致すれば、ACE XML Gateway は、一致したレコードの完全な DN を結果として受け取ります。DN は %d 変数に格納され、これが以降の ACE XML Gateway によるユーザとしてのバインドの試行に使用されます。

ステップ 4 [Bind] 設定で、ACE XML Gateway が、要求から取得したパスワードでのディレクトリへのバインドに使用するユーザ名を設定します。

セットアップ クエリーが設定済みの場合、おそらくこのフィールドには %d と入力することになります(セットアップ クエリーで取得した完全な DN が格納されている変数)。

セットアップ クエリーを使用しない場合は、パラメータ化した DN を設定します。次に例を示します。

cn=%u,cn=Users,dc=Cisco,dc=Com

%u 変数は、要求から取得したユーザ名に置き換えられます。

ステップ 5 [Save Changes] をクリックして、設定内容を作業ポリシーにコミットします。


 

検証方法として [LDAP Bind Request] のリストされたパスワード要件が、オーセンティケータのページに現れます。

LDAP クエリー パスワード検証の使用

LDAP パスワード検証のクエリー モードでは、ACE XML Gateway が LDAP ディレクトリに、指定したフィルタに一致するレコードをクエリーで問い合せ、結果を正規表現でチェックし、その結果に基づいてアクセス決定を下します。

必要であれば、ACE XML Gateway が、クエリーを実行するために、ユーザのクレデンシャルでディレクトリにバインドするようにすることもできます。これには、要求に入れて渡されたパスワードを検証できるという効果もあります。ACE XML Gateway にユーザとしてディレクトリにバインドしてはほしくない場合は、独自のアカウントでバインドするように設定することもできます。

要求から取得したユーザ名が、ディレクトリにバインドするために必要な DN と一致しない場合は、まず LDAP ディレクトリからユーザ DN を取得するセットアップ クエリーを設定する必要があります。

次の図に、最も厳しい検証要件を反映した設定を想定して、ACE XML Gateway と LDAP サーバの間で行われる相互作用を示します。

図 6-5 LDAP クエリー検証シーケンス

 

次の手順では、LDAP バインド検証をセットアップ クエリーで、またはセットアップ クエリーなしで設定する方法を示します。


ステップ 1 パスワードクレデンシャル タイプ(HTTP Basic 認証、WSS Username など)のオーセンティケータ条件では、[Verify Using] メニューから [LDAP Query] を選択します。

[Server]、[Setup Query]、[Query]、および [Result Processing] の設定が現れます。

ステップ 2 使用する LDAP サーバへの接続がすでのポリシー内で定義されている場合は、それを [Server] メニューから選択します。まだ定義されていない場合は、[New LDAP Server] ボタンをクリックして、LDAP サーバとの接続を設定します。

ステップ 3 ACE XML Gateway がディレクトリとのバインドに使用するユーザ DN の取得にセットアップ クエリーを使用するには、次の手順を実行します(この手順の代わりに ACE XML Gateway のディレクトリへのバインドに独自のアカウントを使用させて検証クエリーを実行することもできます。その場合は、この手順は飛ばしてください)。

a. [Perform setup query, storing result DN in substitution variable %d] というラベルのチェックボックスをクリックします。

b. ACE XML Gateway がセットアップ クエリーを実行するためにディレクトリとバインドするときの方法を、[Bind] メニューから選択して指定します。

[anonymously] ディレクトリで匿名アカウントがイネーブルになっており、匿名ユーザがユーザ レコードを検索できるように特権が設定されている場合に選択します。

[with DN specified] ACE XML Gateway に指定したアカウントとバインドさせる場合に選択します。[User DN] フィールドに有効な識別名を入力し、[Password] フィールドと [Repeat Password] フィールドにパスワードを入力します。


) ACE XML Gateway がこの用途に使用するための専用のアカウントをディレクトリ内に作成することを推奨します。アカウントを作成している場合は、ACE XML Gateway のアカウントの DN とパスワードを入力します。


c. [Base DN] フィールドで、ディレクトリ内でのユーザ アカウントの場所を、 cn=Users,dc=Cisco,dc=Com などの DN 形式で指定します。

複数のツリーとフォレストを持つ非常に複雑な LDAP インスタンスがある場合、LDAP ブラウザを使用して、使用できる正しい DN を確認しなければならないこともあります。

d. [Filter] フィールドで、サービス要求を発行したユーザのアカウントを一致させる目的で特定のユーザ プロパティをテストする LDAP フィルタ式を指定します。このマッピングは、要求から得たユーザ名の値が格納されている %u 変数によって補助されます。次に例を示します。

(|(cn=%u)(uid=%u))

指定したベース DN の下の cn プロパティまたは uid プロパティの値が要求から取得したユーザ名と一致すれば、ACE XML Gateway は、一致したレコードの完全な DN を結果として受け取ります。DN は %d 変数に格納され、これが以降の ACE XML Gateway によるユーザとしてのバインドの試行に使用されます。

ステップ 4 [Query] の設定で、ユーザ アトリビュートを評価するためのクエリーを設定します。クエリーの結果は、ポジティブだった場合は LDIF(Lightweight Directory Interchange Format)の一致結果になります。これは、その後、設定されている結果処理式でテストされます。

セットアップ クエリーの場合と同様に、検証クエリーはバインド設定とフィルタで構成されます。バインド試行は、既知の良好な資格条件(ACE XML Gateway 用に作成されたアカウントあんど)で実行することもできれば、サービス要求から取得したクレデンシャルで実行することもできます。ほとんどの場合、この手順にはサービス要求のクレデンシャルが使用されます。これには、そのクレデンシャルを検証できるという効果があります。

検証クエリーを設定するには、次の手順を実行します。

a. ACE XML Gateway が検証クエリーを実行するためにディレクトリとバインドするときの方法を、[Bind] メニューから指定します。

[anonymously] ディレクトリでクエリー特権を持つ匿名アカウント アクセスがイネーブルになっていて、ユーザクレデンシャルでの検証は行いたくない場合に選択します。

[with DN specified] ACE XML Gateway を特定のアカウントとバインドさせる場合に選択します。この場合、さらに[User DN] フィールドに有効な識別名を指定し、そのパスワードも指定します(たとえば、ACE XML Gateway のために作成したアカウント用など)。

要求に入れて渡されたクレデンシャルを検証するには、要求を送ってきたユーザの DN を渡します。これには、セットアップ クエリーで取得した DN か( %d )、またはパラメータ化した DN を使用します(「LDAP バインド パスワード検証の使用」を参照してください)。

ユーザの DN を渡す場合は、[Use password provided by consumer for this credential] というラベルの付いたオプションを選択して、ACE XML Gateway に、サービス要求に入れて渡されたパスワードでバインドさせます。

b. [Base DN] フィールドに、クエリーで問い合せるユーザ アカウントが含まれているディレクトリをタイプします。 cn=Users,dc=Cisco,dc=Com のような値を指定することになります。

複数のツリーとフォレストを持つ非常に複雑な LDAP インスタンスがある場合、LDAP ブラウザを使用して、使用できる正しい DN を確認しなければならないこともあります。

c. [Filter] フィールドで、ユーザのアトリビュートを問い合せる LDAP フィルタ式を指定します。ディレクトリとのバインドに使用されるユーザ DN の場合と同様、場合によっては、使用できるフィルタを定義するために代入変数を使用する必要があります。次に例を示します。

(&(Name=Sales)(Member=%d))

これは、グループの「Name」が「Sales」でなければならず、それがユーザ DN と等しい「Member」アトリビュートを持っていなければならないことを意味します。この例は、「cn=support,cn=users,dc=Cisco,dc=com」のような LDIF 形式のクエリー結果を返します。

d. 必要であれば、[Attributes] フィールドを使用してフィルタから返された情報を減らし、特定の LDAP アトリビュートの値だけにします。複数のアトリビュートを指定して、複数の値を取得することもできます。これを行うには、アトリビュート名をスペースで区切ります。

たとえば、営業担当者の E メール アドレスだけを使用し、他のデータは一切使用しないようにするには、[Attributes] フィールドに「mail」と入力します。これで、クエリーによって返される各レコードについて、 mail アトリビュートのリストだけが返されます。[Attributes] フィールドを使用してフィルタにより返される値を絞ると、結果を検証するために指定する必要のある [Match Regex] を簡単にすることができます。

ステップ 5 検証クエリーの結果は、ディレクトリから取得した 1 つまたは複数のレコードです。結果は、結果処理式でチェックできます。結果処理式は、フィルタによって返された結果の検証に使用されます。

ユーザ データをテストする、つまりデータ内に一致する表現が見つかった場合にこのオーセンティケータ条件の中でユーザに許可を与える正規表現を入力します。たとえば、返されたグループが sales グループであることを確認するには、.*sales.* と入力します。

LDIF 出力は常にすべて小文字になるため、正規表現はストリングの小文字になったものと一致するようにしてください。


) LDAP のスキーマと要件によっては、使用すべき正しいフィルタと結果処理式に到達するのは、そんなに単純なことではない場合もあります。Softerra™ LDAP Browser(http://www.softerra.com)などの LDAP ツールを使用してクエリーを送信し、要件に最適な正規表現にカスタマイズすれば、作業しやすくなります。


ステップ 6 [Save Changes] をクリックして、設定内容を作業ポリシーにコミットします。


 

検証方法として [LDAP Query] のリストされたパスワード要件が、オーセンティケータのページに現れます。

オーセンティケータごとの XML セキュリティ公開鍵の使用

ユーザの公開鍵をオーセンティケータに関連付けることにより、ユーザの証明書を、オーセンティケータによって受け付けられたメッセージのために XML 暗号化と XML 署名検証タスクの中で使用できます。この機能は、さまざまなユーザの証明書を XML セキュリティ処理タスクに使用しながら、仮想サービスがさまざまなユーザからの受信メッセージを受け付けることを可能にします。つまり、各サービス ユーザに別々の仮想サービスを要求する(異なるクライアント鍵に対応するために)代わりに、この特殊化をオーセンティケータ内に置くことでできるのです。


) このオーセンティケータ鍵は、メッセージの内容の処理にしか使用されません。別の設定で、ACE XML Gateway がこのオーセンティケータのためにユーザとの HTTPS 接続を確立するのに使用する X.509 公開鍵を指定します(オーセンティケータに [SSL/TLS Certificate] 条件を追加することにより設定できます)。


オーセンティケータの鍵を設定したら、図 6-6 に示すとおり、サービスハンドラ設定の該当するエリアで [consumer's XML security public key] オプションを選択することにより、それをメッセージ処理に適用できます。この図は、任意の SOAP サービス オブジェクトの [SOAP Header Processing] ページからアクセスできる XML 署名設定の画面に表示されるオプションを示しています。

図 6-6 ユーザの鍵での XML 署名の検証

 

オーセンティケータの XML セキュリティ公開鍵を設定する手順を次に示します。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス条件を設定するオーセンティケータをクリックするか、新しいオーセンティケータを作成します。

ステップ 3 情報ページの [General] セクションの [Edit] リンクをクリックします。

ステップ 4 [XML Security Public Key] メニューに公開鍵リソースが表示されない場合は、[Upload] ボタンをクリックし、[Upload Consumer Certificate Resource] ページを使用して、ユーザ証明書の一覧にそれを追加します。

ステップ 5 [Edit General Information] ページのメニューから、新しい XML セキュリティ公開鍵リソースを選択します。

ステップ 6 必要であれば、[Set the name of this Authenticator to the CN from this Consumer Certificate] というラベルの付いたオプションを選択することにより、オーセンティケータの名前を証明書の CN 値から取得します。

イベント ログでは、このオーセンティケータによって許可されたサービス アクセス イベントの識別にこの名前が使用されます。

ステップ 7 [Save Changes] をクリックして、変更内容を作業ポリシーに保存します。


 

これで、オーセンティケータに関連付けられている仮想サービスでのメッセージ処理仕様を、このオーセンティケータ用に設定されているユーザ証明書を使用するように設定できます。

ID 報告

ACE XML Gateway は、ユーザの ID に基づいた使用状況情報をレポートできます。ID 報告が得られるのは、オーセンティケータによって検証されたクレデンシャルがユーザ名/パスワードクレデンシャルのユーザ名、SAML トークンのサブジェクト ID などで特定のユーザと結び付けられている場合です(これに対し、Time-of-Day オーセンティケータのチェックは特定のユーザと結び付けられません)。

ACE XML Gateway は、要求の数や要求サイズなどのユーザ ID によるアクティビティをレポートできます。この情報は、パフォーマンス モニタおよびエクスポートされたパフォーマンス統計情報ファイルに表示されます。

多くの場合、ネットワーク攻撃は 1 つまたは 2 ~ 3 個のユーザ アカウントで追跡できるため、トリガーされるトラフィックしきい値を 1 つのユーザ アカウントに関連付けられているアクティビティで設定できます。ユーザ アカウントのサービス アクセスは、他のユーザに影響することなくブロックできます。

ユーザ ID 設定は、オーセンティケータ内に置かれます。オーセンティケータは、クレデンシャルの性質に応じて、1 つの ID にも多数の ID にも関連付けることができます。たとえば、パスワード ファイル(htaccess)によってクレデンシャルをチェックするオーセンティケータは、ファイル内にあるユーザ名/パスワードの組み合わせの数だけの ID に関連付けられます。

ユーザ ID を確立できるクレデンシャルには、次のものがあります。

IP アドレス

SSL/TLS 証明書

XPath パスワード、WSS UsernameToken を含むパスワード ベースのクレデンシャル

SAML トークン

オーセンティケータ内のクレデンシャル タイプがユーザ ID を提供する場合、ユーザ ID を設定する設定値は使用できません。

ID 報告機能のイネーブル化

ユーザ ID 報告としきい値適用は、オーセンティケータによってイネーブル化されます。ユーザ ID 報告としきい値制限をイネーブルにする手順は次のとおりです。


ステップ 1 Web コンソールに Administrator ユーザまたは Access Control ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Access Control Browser] リンクをクリックします。

ステップ 2 アクセス条件を設定するオーセンティケータをクリックするか、新しいオーセンティケータを作成します。

ステップ 3 [Identity Reporting] の横にある [Edit] リンクをクリックします。

オーセンティケータがユーザを識別できるクレデンシャルを要求する場合は、[Edit Identity Reporting] ページが表示されます。オーセンティケータがユーザ ID を許可するクレデンシャルを使用していない場合は、その事実を示すメッセージが表示されます。

ステップ 4 [Enable Identity Reporting] チェックボックスを選択します。

このページ上のその他のチェックボックスがイネーブルになります。このオーセンティケータで使用されているクレデンシャル タイプが [Service Users Identifiers] エリアに表示されます。

ステップ 5 ACE XML Gateway によるユーザの識別に使用するクレデンシャル タイプを [Service Users Identifiers] エリアから選択します。

たとえば、[IP Address] を選択すると、ユーザ固有のアラートとしきい値のために、有効なユーザの IP アドレスが保持され、ユーザの識別に使用されます。

必要であれば、複数のクレデンシャル タイプを選択できます。複数のクレデンシャル タイプを選択した場合は、すべての要求が同じユーザから送られてきていると見なされるため、選択したすべてのクレデンシャルの値が要求の間で一致していなければなりません。つまり、IP アドレスと WSS UsernameToken をクレデンシャル タイプとして選択した場合、同じユーザ名を持つけれども異なる送信元 IP アドレスを持つ 2 つの要求は、同じユーザからのものとは見なされません。ところが、ユーザ ID として WSS Username だけを選択していた場合は、同じユーザからのものと見なされます。

ユーザ ID に関連した統計情報を表示したいだけの場合は、オーセンティケータ内でその他のオプションを設定する必要はありません。保存して導入すれば、ID ベースのアクティビティのロギングの収集と表示を開始できます。詳細については、「ユーザ アクティビティ情報の表示」を参照してください。

ステップ 6 [Alert Thresholds] エリアで、次の手順で識別されたユーザのアラートとブロックのしきい値を指定します。

a. ログ イベントをユーザ アクティビティに基づいて作成されるようにするには、[Log a Warning-level event when a Service User authenticates via this Authenticator more than] オプションを選択し、1 分間当たりのオプションとバースト オプションを設定します。

[times per minute] には、1 分間当たりの認証イベントの数で、超過した場合にログ イベントを発生させる数を指定します。

[times at once ("burst")] には、バースト レベルを、つまり同時に許可される認証試行の数を指定します。


) これらの設定の詳細については、「トラフィック レートのしきい値について」を参照してください。


b. [Block requests from any Service User who authenticates via this Authenticator more than] を選択することにより、以降の認証試行がブロックされるようにできます。このオプションには、次の設定値を設定できます。

[times per minute] には、1 分間当たりの認証イベントの数で、超過した場合にユーザがブロックされるようになる数を指定します。

[times at once ("burst")] には、バースト レベルを、つまりほぼ同時に許可される認証試行の最大数を指定します。


) これらの設定の詳細については、「トラフィック レートのしきい値について」を参照してください。


しきい値設定の結果としてユーザがブロックされた場合に、そのブロックを何秒間継続させるかを [Block for at least] フィールドに指定します。

ステップ 7 [Save Changes] をクリックして、変更内容を作業ポリシーにコミットします。


 

ポリシーを導入して、ACE XML Gateway への変更内容を反映させます。

ユーザ アクティビティ情報の表示

ACE XML Gateway のポリシーでユーザ ID 機能をイネーブルにした後は、ユーザごとのアクティビティに関する統計情報を表示できます。


ステップ 1 操作メニューの [Performance Monitor] リンクをクリックします(メニューの [Reports and Tools] エリアにあります)。

ステップ 2 ユーザ情報を表示するヘッダー グループを展開します。識別されたユーザのユーザ統計情報が、ユーザ名ごとにリストに表示されます。

図 6-7 パフォーマンス モニタに表示されたユーザのアクティビティ

 


 


) パフォーマンス モニタでの統計情報については、パフォーマンス モニタのページからオンライン ヘルプ ページを表示してください。


サービスのメッセージ トラフィック ロギングがイネーブルになっている場合は、次のようにして、ユーザごとにトラフィック ログを検索できます。


ステップ 1 操作メニューで [Reports and Tools] カテゴリの [Message Traffic Log] リンクをクリックします。

ステップ 2 メッセージ トラフィック ログの [Simple Search] ペインで、[User Search] タブをクリックします。

識別されたユーザに関連付けられているトラフィックが、トラフィック リストに表示されます。

ステップ 3 特定のユーザ ID のトラフィックを検索するには、[for User] フィールドにユーザ名を入力し、[Update View] をクリックします。ユーザ検索結果がページに表示されます。