26.2 Access Manager 11gのアクセス・テスターの概要

アクセス・テスターは移植可能なスタンドアロンのJavaアプリケーションで、Access Manager 11gに同梱されています。アクセス・テスターは、個々のIT専門家や管理者とOAMサーバー間の機能的なインタフェースを提供します。

IT専門家はアクセス・テスターを使用して接続を検証し、物理的デプロイメントのトラブルシュートを行うことができます。アプリケーション管理者は、アクセス・テスターを使用してポリシーを迅速に検証できます。この章で言う「管理者」とは、アクセス・テスターを使用する人物を表します。

アクセス・テスターは、OAMサーバーへのネットワーク接続を持つ任意のコンピュータから使用できます。また、グラフィカル・ユーザー・インタフェース(この章ではテスター・コンソールと呼びます)とコマンド行インタフェースの両方を使用できます。コマンド行モードを使用すれば、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。

実際のエージェントのように見せることによって、アクセス・テスターはポリシー構成設計やトラブルシューティングを助け、場合によってはOAMサーバーの応答性に関するトラブルシューティングに使用することもできます。アクセス・テスターを使用するときは実際のエンド・ユーザーのように振る舞う必要がありますが、アクセス・テスターが実際にエンド・ユーザーと通信することはありません。

アクセス・テスターを使用するには、Access Managerによって保護されるアプリケーションまたはリソースの認証ポリシーと認可ポリシーを理解し、管理する必要があります。

アクセス・テスターを使用すれば次のことが可能です。

エミュレート用のOAMサーバーに送信するリクエストの構成。エミュレート用OAMサーバーは、実際のエージェントが本番環境のOAMサーバーに送る内容をエミュレートします。
リクエストをOAMサーバーに送信し、実際のエージェントが受信する応答と同じ応答を受信。アクセス・テスターはOAMアクセス・プロトコル(OAP) APIを使用し、OAMチャネルを介して、OAMサーバーの一部として実行中のOAMプロキシにリクエストを送信します。OAMサーバーはこのリクエストを処理してレスポンスを返します。
サーバー・レスポンスの処理と表示。
実際のエージェントによるレスポンスの取り扱いと同様に処理を続行。たとえば、Webgateがリソースは証明書認証スキームによって保護されていると判断した場合、Webgateはhttp SSL接続からエンド・ユーザーの証明書を取得する必要があります。

証明書認証スキームの場合、アクセス・テスターにはエンド・ユーザーの資格証明として使われる証明書を参照させなければなりません。

前述の機能を実行してエージェントをシミュレートすることに加えて、アクセス・テスターによって次の操作を行うことができます。

予定しているポリシー変更のパフォーマンス特性の確認
認証リクエストと認可リクエストの待機時間の追跡
OAMサーバーのストレス・テストを実施してユーザー負荷に関連するローパフォーマンス・ウォーターマークまたはハイパフォーマンス・ウォーターマークを確立し、バックエンド・ハードウェアのサイズを決定
コマンド行モードのみで複数の同時テスト(マルチスレッド・モード)を実行することにより、ポリシー・サーバーのストレス・テストを実施します。
継続的にパフォーマンス・メトリックの確立と測定を行い、求められていた成果を検証

基本的な動作中、アクセス・テスターはサーバー・レスポンスに関して何の判定も行なわず、そのレスポンスの可否判定も行いません(たとえばリソースXが保護されているかどうか、あるいはユーザーYがリソースXへのアクセスを認可されているかどうかなど)。アクセス・テスターを操作するときは、特定のレスポンスが適切なものかどうかを決定するポリシー構成に注意する必要があります。

アクセス・テスターは、複数の個別リクエストをグループ化してテスト・スクリプトにまとめ、それをOAMサーバーに送って処理することを可能にする拡張機能を備えています。このようなテスト実行の出力はアクセス・テスターで取得し、「確認済の」応答を含む同様ドキュメントとの比較に使用することができます。このように、アクセス・テスターは、ポリシー構成の誤変更検出用の自動化テストに使用することができます。

また、アクセス・テスターには、ポリシー・サーバーのストレス・テストを実施する目的でマルチスレッド機能が提供されています。マルチスレッドによる方法では、ポリシー・サーバーに接続する仮想テスト・クライアントの数、および各仮想クライアントでテスト・スクリプトを実行する反復回数を特定します。これにより、ポリシー・サーバーのストレス・テストを実施できます。

詳細については、この章の次の説明を参照してください。

26.2.1 OAMエージェントおよびサーバーの相互運用性について

OAMアーキテクチャにおける2つの主要なアクター・タイプは、ポリシー・サーバー(OAMサーバー)とOAMポリシー強制エージェント(Webgateまたはアクセス・クライアント)です。セキュリティ分野においてはエージェントがポリシー強制点(PEP)を表し、OAMサーバーがポリシー決定点(PDP)を表します。

エージェントはhttpベース・アプリケーションなどのリソースのセキュリティを確保するゲートキーパーの役割を果たし、そのリソースにアクセスしようとするユーザーとのすべての対話操作を管理します。これは、ポリシー・サーバー(OAMサーバー)に保持されているアクセス制御ポリシーに従って実現されます。
OAMサーバーの役割は、エージェントに対してポリシー・サービス、アイデンティティ・サービス、およびセッション・サービスを提供してアプリケーション・リソースに対する適切なセキュリティを確保し、ユーザーの認証と認可を行なって、ユーザーセッションを管理することです。

この中核的なOAM製品アーキテクチャは、エージェントとOAMサーバー間の相互動作を支配する次のようなやり取りを中心に展開します。相互運用性と重要な決定点を明らかにするために、ユーザーがリソースに関するリクエストを行う際のOAMエージェントとOAMサーバー間の標準的な相互動作を図26-1に示します。

図26-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性

「図26-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性」の説明

次の概要では、OAMエージェントとOAMサーバー間で行われる処理を説明します。テストの際は管理者がエンド・ユーザーの役割を果たしながら、アクセス・テスターがエージェントをエミュレートしてOAMサーバーと通信を行います。

プロセス概要: OAMエージェントとOAMサーバーの相互運用性

サーバー接続の確立: 登録OAMエージェントがOAMサーバーに接続します。
ユーザーがリソースへのアクセスをリクエストします。
リソース保護の検証: エージェントがOAMサーバーにリクエストを送って、リソースが保護されているかどうかを判断します。

保護されている場合: OAMサーバーは必要な資格証明のタイプで応答します。
ユーザー資格証明: ユーザー・アイデンティティが確立されると、監査およびSSOのための追跡とアプリケーションへの伝達が可能になります。このため、エージェントはユーザーに対して資格証明を求めます。
ユーザー資格証明の認証: エージェントは、提供されたユーザー資格証明を検証のためOAMサーバーに送ります。

認証の成功: エージェントはリソース・リクエストをOAMサーバーに送ります。
リソースへのユーザー・アクセスを認可: エージェントはまず、認可ポリシーの検証のためにOAMサーバーへアクセス・リクエストを送ることによって、リソースへのユーザーのアクセスを認めるかどうかを判定しなければなりません。
エージェントは、ポリシー応答に基づいてアクセスを認可または拒否します。

26.2.2 アクセス・テスターのセキュリティおよび処理について

この項では、セキュアな通信、接続、保存、入力、ロギングおよび分析に関する情報を説明します。

セキュアな通信: アクセス・テスターは、OAMサーバーとの通信について、オープン接続モード、簡易接続モードまたは証明書接続モードに対応しています。

オープン・モード: 物理的接続に対するセキュリティがありません。
簡易モード: 組込み証明書を使用して物理的接続を暗号化します。簡易モードでは、OAMサーバー用に構成されたグローバル・パス・フレーズの入力を求められます。
証明書モード: フィールド提供の証明書を使用して物理的接続を暗号化します。アクセス・テスターの証明書モードでは、次を実行する必要があります。
- 証明書モードの通信用にエージェント(既存または新規)を構成します。
- エミュレートするエージェントの証明書を取得します。

アクセス・テスターの証明書モードでは、提供されたPEM (BASE64-コード化ASCII)証明書(aaa_trust.pem、aaa_key.pem、aaa_cert.pem)からimportcertツールを使用して作成した2つのJKSキーストアが必要です。

トラスト・ストア(ルートCA証明書を持つJKSキーストアが含まれるファイル)が必要です。
キー・ストア(エージェントの秘密キーおよび証明書を持つJKSキーストアが含まれるファイル)が必要です。
エージェント証明書を持つキーストアの暗号化には、キーストア・パスワードを使用します。

26.2.3 アクセス・テスターのモードおよび管理者の操作について

この項では、モード、対話操作およびアクセス・テスターの起動と実行に必要なjarファイルについて説明します。

コンソール: アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行うことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。

コマンド行およびスクリプト: アクセス・テスターでコマンド行を使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成できます。

起動および実行時JARファイル: アクセス・テスターでは、アプリケーションの起動に使用するメインjarのoamtest.jarと同じディレクトリにnap-api.jarを置く必要があります。

対話操作: アクセス・テスター実行のために選択したモードにかかわらず、ユーザーとアクセス・テスターの主な対話操作には次の操作が含まれます。

リクエストの発行と結果の表示

リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。

テスト・スクリプトの管理

テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後に何らかの自動分析を行うことができます
OAMサーバー接続の管理

サーバー接続情報を含むアプリケーション設定を管理することができます。

コンソール・モード操作とコマンドライン・モード操作の両方おける情報の流れを図26-2に示します。詳細は、図の後に説明します。より高度な操作としては、テスト・スクリプトの作成と実行があります。

ノート:

コマンド行モードを使用すると、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。アクセス・テスターは、読取り専用モードで使用可能な「確認済(Known Good)」の入力テスト・スクリプトを変更せずにテスト実行を構成する制御メカニズムを公開しています。

図26-2 アクセス・テスターのユーザー操作

「図26-2 アクセス・テスターのユーザー操作」の説明

テスター・コンソール・モード操作とコマンド行モード操作の両方における情報の処理フローを表26-1に示します。

表26-1 ユーザー操作: テスター・コンソール・モードとコマンド行モードの操作

テスター・コンソール・モード	コマンド行モード
ユーザーはコマンド行からアクセス・テスターを開始します。	コマンド行モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。セキュアな通信用の証明書モード: キーストアは、以前に保存された構成情報が格納されているOamTestConfiguration.xmlファイルで指定されます。
ユーザーが前に保存されたOamTestConfiguration.xmlファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、テスター・コンソールを使用して手動でデータを入力することもできます。	アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。
ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。	入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。
リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。	リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。
アクセス・テスターはテスト完了時に次のものを作成します。結果のスクリプト一致しないレスポンスに関する情報を含む実行統計のファイル処理フローの詳細を示すログ・ファイル	アクセス・テスターはスクリプト完了時に次のものを作成します。結果のスクリプト一致しないレスポンスに関する情報を含む実行統計のファイル処理フローの詳細を示すログ・ファイル
必要に応じてユーザーがステップを繰り返して検証を終了させます。	必要に応じてユーザーがステップを繰り返して検証を終了させます。
証明書モードでは、必要なキーストアを特定するように要求されます。	証明書モードでは、キーストアは、以前に保存された構成情報が格納されているXMLファイルで指定されます。

以下ではアクセス・テスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。

タスクの概要: Access Managerの接続とポリシーのテスト

次のトピックを確認します。
- アクセス・テスターのインストールと起動
- アクセス・テスター・コンソール、ナビゲーションおよびコントロール
「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行して取得します。
「テスト・ケースおよびスクリプトの作成と管理」に進みます。