26 アクセス・テスターを使用した接続性およびポリシーの検証
IT専門家や管理者はアクセス・テスターを使用して、リクエストやレスポンス・セマンティクス、アクセス・ポリシー設計の高速テストを行ったり、サーバー接続のエージェントの問題をトラブルシューティングできます。
次の各トピックでは、アクセス・テスターとその使用方法について説明します。
26.1 アクセス・テスターを使用して接続性とポリシーを検証するための前提条件
接続性とポリシーの検証を続行する前に、システム・レベル要件が満たされていることを確認します。
次に、この章のタスクを実行するための要件を示します。
-
Oracle Access ManagementコンソールおよびOAMサーバーが実行中であることを確認します。
-
「リソースの保護およびSSOの有効化ポリシーの管理」の説明に従い、1つ以上のリソースのアプリケーション・ドメインとポリシーを確認します。
26.2 Access Manager 12cのアクセス・テスターの概要
アクセス・テスターは移植可能なスタンドアロンのJavaアプリケーションで、Access Manager 12cに同梱されています。アクセス・テスターは、個々の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に示します。
次の概要では、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キーストアが含まれるファイル)が必要です。
-
エージェント証明書を持つキーストアの暗号化には、キーストア・パスワードを使用します。
関連項目:
-
OAMサーバーおよびクライアント(Webgate)用の簡易モード構成および証明書モード構成の詳細は、「通信の保護」を参照してください。
接続: アクセス・テスターは、テスターが構成ファイルとテスト・ケースに保存するすべてのパスワード型の値を暗号化します。プールに有効な接続が含まれているかどうかがアクセス・テスターで検証されます。OAPの(ログアウトをシミュレートする)ユーザー・セッションを削除するためのキャッシュ・フラッシュ・リクエストが(帯域外接続ではなく)確立された接続を介して送信されます。すでに確立された接続を使用することにより、パフォーマンスが向上します。
永続的な保存: アクセス・テスターは、アクセス・テスターを次回起動するまで永続的に保存しておく必要のある複数のデータ構造を管理します。次の種類の情報については、XMLファイルベースで保存が行われます。
-
アプリケーション再起動時のデータ入力をできるだけ少なくするための構成データ(OamTestConfiguration)
-
取得されたテスト・ケースで構成されるテスト・スクリプト(OamTestScriptCase)
-
テスト実行の実行メトリックを表す統計データ(OamTestStats)
入力、ロギングおよび分析用のXMLファイル: アクセス・テスターでは、単一のXMLスキーマを使用して、生成したすべてのXMLドキュメントを定義します。テスト・スクリプトを処理するためにアクセス・テスターを実行すると、次のXMLファイルが生成されます。
-
構成スクリプト: config.xmlは、アクセス・テスター内でSave Configurationコマンドを使用して作られる出力ファイルです。このドキュメントの名前は、コマンド行モードで実行中のアクセス・テスターに正しい接続情報を提供するために入力スクリプト内で使われます。詳細は、「保存された接続構成ファイル」を参照してください。
-
入力スクリプト: script.xmlは、1つまたは複数のテスト・ケースを取得後にアクセス・テスターによって作られるスクリプトです。詳細は、「生成された入力テスト・スクリプト」を参照してください。
-
ターゲット出力スクリプト: アクセス・テスターをコマンド行モードで実行して入力スクリプトを指定すると、oamtest_target.xmlが作成されます。詳細は、「テスト実行結果が格納されたターゲット出力ファイル」を参照してください。たとえば:
-Dscript.scriptfile="script.xml" -jar oamtest.jar
-
統計: oamtest_stats.xmlは出力スクリプトとともに作成されます。詳細は、「統計ドキュメント」を参照してください。
-
実行ログ: lamtest_log.logは出力スクリプトとともに作成されます。詳細は、「実行ログ」を参照してください。
その他の詳細は、「アクセス・テスターのモードおよび管理者の対話操作について」を参照してください。
26.2.3 アクセス・テスターのモードおよび管理者の操作について
この項では、モード、対話操作およびアクセス・テスターの起動と実行に必要なjarファイルについて説明します。
コンソール: アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行うことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。
コマンド行およびスクリプト: アクセス・テスターでコマンド行を使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成できます。
起動および実行時JARファイル: アクセス・テスターでは、アプリケーションの起動に使用するメインjarのoamtest.jarと同じディレクトリにnap-api.jarを置く必要があります。
対話操作: アクセス・テスター実行のために選択したモードにかかわらず、ユーザーとアクセス・テスターの主な対話操作には次の操作が含まれます。
-
リクエストの発行と結果の表示
リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。
-
テスト・スクリプトの管理
テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後に何らかの自動分析を行うことができます
-
OAMサーバー接続の管理
サーバー接続情報を含むアプリケーション設定を管理することができます。
コンソール・モード操作とコマンドライン・モード操作の両方おける情報の流れを図26-2に示します。詳細は、図の後に説明します。より高度な操作としては、テスト・スクリプトの作成と実行があります。
ノート:
コマンド行モードを使用すると、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。アクセス・テスターは、読取り専用モードで使用可能な「確認済(Known Good)」の入力テスト・スクリプトを変更せずにテスト実行を構成する制御メカニズムを公開しています。
テスター・コンソール・モード操作とコマンド行モード操作の両方における情報の処理フローを表26-1に示します。
表26-1 ユーザー操作: テスター・コンソール・モードとコマンド行モードの操作
テスター・コンソール・モード | コマンドライン・モード |
---|---|
ユーザーはコマンド行からアクセス・テスターを開始します。 |
コマンド行モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。 セキュアな通信用の証明書モード: キーストアは、以前に保存された構成情報が格納されているOamTestConfiguration.xmlファイルで指定されます。 |
ユーザーが前に保存されたOamTestConfiguration.xmlファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、テスター・コンソールを使用して手動でデータを入力することもできます。 |
アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。 |
ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。 |
入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。 |
リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。 |
リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。 |
アクセス・テスターはテスト完了時に次のものを作成します。
|
アクセス・テスターはスクリプト完了時に次のものを作成します。
|
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
証明書モードでは、必要なキーストアを特定するように要求されます。 |
証明書モードでは、キーストアは、以前に保存された構成情報が格納されているXMLファイルで指定されます。 |
以下ではアクセス・テスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。
タスクの概要: Access Managerの接続とポリシーのテスト
-
次のトピックを確認します。
-
「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行して取得します。
-
「テスト・ケースおよびスクリプトの作成と管理」に進みます。
26.3 アクセス・テスターのインストールと起動
アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できる2つのjarファイルで構成されます。アクセス・テスターのインストールでは、テストを実行するコンピュータにアクセス・テスターのjarファイルをコピーします。テスト入力用に選択したモードがテスター・コンソール・モードかコマンド行モードかにかかわらず、アクセス・テスターはコマンド行から開始する必要があります。
この項の内容は次のとおりです。
26.3.1 アクセス・テスターのインストール
このトピックでは、どのコンピュータでも使えるようにアクセス・テスターをインストールする方法を説明します。
インストール終後は、いつでもアクセス・テスターを使用することができます。特別なセットアップは必要ありません。
アクセス・テスターのインストール方法
26.3.2 アクセス・テスターでサポートされているシステム・プロパティ
アクセス・テスターでは、プレゼンテーションに使用したりテストの特定側面に使用したりすることのできるいくつかの構成オプションを選択することができます。これらのオプションは、起動時にJavaの-Dメカニズムを使用して指定します。
表26-2では、サポートされているすべてのシステム・プロパティについて説明します。
表26-2 アクセス・テスターでサポートされているシステム・プロパティ
プロパティ | アクセス・テスター・モード | 説明とコマンド構文 |
---|---|---|
log.traceconnfile |
テスター・コンソール・モードおよびコマンド行モード |
指定ファイル名への接続詳細を記録します。 -Dlog.traceconnfile="<file-name>" |
display.fontname |
テスター・コンソール・モード |
指定フォントでアクセス・テスターを開始します。これは、表示解像度の違いの補正に有効です。 - Ddisplay.fontname ="<font-name>" |
display.fontsize |
テスター・コンソール・モード |
指定フォント・サイズでアクセス・テスターを開始します。これは、表示解像度の違いの補正に有効です。 - Ddisplay.fontsize ="<font-size>" |
display.usesystem |
テスター・コンソール・モード |
デフォルトのフォント名とフォント・サイズ(ダイアログ・フォント、サイズ10)でアクセス・テスターを開始します。 - Ddisplay.usesystem |
script.scriptfile |
コマンドライン・モード |
コマンド行モードでスクリプト<file-name>を実行します。 -Dscript.scriptfile="<file-name>" |
control.configfile |
コマンドライン・モード |
接続情報を含む構成XMLファイルへの絶対パスが格納されている、スクリプトの「configfile」属性を上書きします。アクセス・テスターはこの構成ファイルを使用して、「接続」要素によって示されたポリシー・サーバーへの接続を確立します。 -Dcontrol.config="<file-name>" |
control.testname |
コマンドライン・モード |
出力スクリプト・ファイル、統計ファイルおよびログ・ファイルの命名に使用するテスト・シリーズの名前を表す文字列が格納されている、スクリプトの制御要素の「testname」属性を上書きします。出力ログ・ファイルは<testname>_<testnumber>で始まります。 -Dcontrol.testname="<String>" |
control.testnumber |
コマンドライン・モード |
出力スクリプト・ファイル、統計ファイル、およびログ・ファイルの命名に使用する制御番号を指定します。出力ログ・ファイルは<testname>_<testnumber>で始まります。 -Dcontrol.testnumber="<String>". 自動生成される文字列は現在のローカル時刻に基づく7桁の数値ですが(分数を示す2文字+秒数を示す2文字+1/100秒を示す3文字)、ファイル名に使用できるものであれば任意の文字列を使用して制御番号を表すことができます。 |
control.ignorecontent |
コマンドライン・モード |
スクリプトの「制御」要素の「ignorecontent」属性を上書きします。この要素は、アクセス・テスターがオリジナルのテスト・ケースと現在の結果における「コンテンツ」の違いを無視する必要があることを示します。 -Dcontrol.testname="true|false" |
control.displayiterationstats |
コマンドライン・モード |
テスト実行を反復するたびに中間統計を表示するかどうかを制御します。 -Dcontrol.displayiterationstats="true|false" |
control.loopback |
コマンドライン・モード |
確認済のスクリプトを基準にアクセス・テスターの内部的な性能低下をテストするために、アクセス・テスターをループバック・モードで実行します。アクセス・テスターのユニット・テストに使用します。 -Dcontrol.loopback="true" |
26.3.3 テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する
グラフィカル・ユーザー・インタフェースを通じて手動でリクエストを行って(結果を取り込み)リアルタイム応答を表示するには、テスター・コンソール・モードでテスターを開始します。テスター・コンソール・モードでもいくつかのシステム・プロパティを使用できますが、この手順ではすべて省略します。
jarファイルはデフォルトの開始クラスを定義します(クラス名を指定する必要はありません)。oamtest.jarと同じディレクトリ内にnap-api.jarが存在することを確認してください。
システム・プロパティを使わずにコンソール・モードでシステム・テスターを開始する方法
26.3.4 コマンド行モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する
この項の内容は次のとおりです。
26.3.4.1 アクセス・テスターのコマンド行モードについて
テスト・スクリプトを実行したりアクセス・テスターの動作をカスタマイズしたりするには、コマンド行モードでテスターを開始し、Javaの-Dオプションを使ってシステム・プロパティを含めなければなりません。
コマンド行モードでアクセス・テスターを実行すると、アクセス・テスターは、テスト実行管理のためのシェル・スクリプトで使用できる完了コードを返します。コンソール・モードでアクセス・テスターを実行するときは、アクセス・テスターによって返されるコードに従う必要はありません。
特定のテスト・ケースを実行するためにアクセス・テスターをラップするシェル・スクリプトは、アクセス・テスターによって伝達される終了コードを認識し、これに従って動作できる必要があります。コマンド行モードでは、アクセス・テスターはSystem.Exit (N)を使用して終了します(Nは次のいずれかのコードになります)。
-
0は、不一致なしですべてのテスト・ケースが正常に終了したことを示します。これには、入力スクリプト内にテスト・ケースが定義されていない状況も含まれます。
-
3は、少なくとも1つの不一致ですべてのテスト・ケースが正常に終了したことを示します。
-
1は、エラーによってアクセス・テスターを実行できなかったこと、またはテスト・ケースを完了できなかったことを示します。これには、入力スクリプトが指定されていない、入力スクリプトを読み込めない、サーバー接続を確立できない、ターゲット・スクリプトを作成できないという状態が含まれます。
これらの終了コードは、アクセス・テスターを使って特定のテスト・ケースを実行するために作られたシェル・スクリプト(Bourneシェルの$?)によって取得することができます。
26.4 アクセス・テスター・コンソール、ナビゲーションおよびコントロール
アクセス・テスター・コンソールを使用して、OAMサーバーへの接続の確立、リソースの保護ステータスの検証、および認証と認可の確認を行うことができます。
固定サイズのアクセス・テスター・コンソールを図26-3に示します。コンソール・モードでアクセス・テスターを開始した場合、ユーザーはこのウィンドウを通じてアプリケーションとの対話操作を行うことができます。このウィンドウのサイズを変更することはできません。詳細は、図の後に説明します。
メイン・ウィンドウの最上部にあるメニュー・バーにはメニュー名が表示されています。メニュー・バーの下にはツール・バーがあります。ツール・バーのボタンに示されているすべてのコマンドは、メニュー・コマンドとしても使用できます。アクセス・テスター・コンソールは、表26-3に示すとおり、4つのパネルに分かれています。
表26-3 アクセス・テスターのコンソール・パネル
パネル名 | 説明 |
---|---|
サーバー接続 |
OAMサーバー(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)との接続を確立するために必要な情報を入力するためのフィールドと、「接続」ボタンがあります。 関連項目: 「アクセス・テスターとOAMサーバー間の接続の確立」も参照してください。 |
保護リソースのURI |
保護状態を検証する必要のあるリソースに関する情報が表示されます。リソース検証サーバー・リクエストを送信するには、「検証」ボタンを使用します。 |
ユーザー・アイデンティティ |
資格証明を認証する必要のあるユーザーに関する情報が表示されます。「ユーザーの認証」サーバー・リクエストの送信には「認証」ボタンを使用します。 |
ステータス・メッセージ |
ユーザーのリクエストに対してアプリケーションが表示するメッセージで構成された、スクロール可能なステータス・メッセージ・エリアが表示されます。「ユーザーの認可」サーバー・リクエストの送信には認可ボタンを使用します。 関連項目: 「リクエスト待機時間の監視」も参照してください。 |
テキスト・フィールドでは、右クリックによる「編集」メニューの表示、およびマウスとカーソルによるドラッグアンドドロップ操作が可能です。
OAMサーバーにテスト・リクエストを送信するために使用する4つのプライマリ・ボタンがあります。それぞれのボタンは、表26-4に示す指定アクションを開始するためのトリガーとして働きます。
表26-4 アクセス・テスター・パネルのコマンド・ボタン
パネル・ボタン | 説明 |
---|---|
接続 |
接続情報を送信して接続を開始します。 |
検証 |
「保護リソースのURI」パネルに入力された情報を送信して、保護の検証を開始します。 |
認証 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認証の確認を開始します。 |
認可 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認可の確認を開始します。 |
26.4.1 アクセス・テスターのメニューとコマンド・ボタン
アクセス・テスター・コンソールのその他のコントロール・ボタンおよびコマンド・ボタンでは、カーソルをボタンの上に置くとヒントが表示されます。
アクセス・テスターのその他のボタンとその使用方法を表26-5に示します。
表26-5 その他のアクセス・テスター・ボタン
コマンド・ボタン | 説明 |
---|---|
開いたフォルダ |
XMLファイル(デフォルトはconfig.xml)に保存された接続構成の詳細をロードします。 このボタンをクリックすると、コンソール内の情報をリフレッシュすることができます。 |
ディスク |
接続構成の詳細をファイル(デフォルト名はconfig.xml)に保存します。このドキュメントの名前は、コマンド行モードで実行中のアクセス・テスターに正しい接続情報を提供するために、入力スクリプトに追加できます。 コンソールの一番下にある「保存」コマンド・ボタンは、「ステータス・メッセージ」パネルの内容をログ・ファイルに保存します。 |
消しゴム |
アイコンを含むパネル上のフィールドをクリアします。ツール・バーのボタンを使用すると、接続がすでに確立されている場合は接続フィールドを除くすべてのフィールドがクリアされます。 |
青色の上向き矢印 |
最後に指定されたリクエストを取得し、これに対してOAMサーバーから受信したレスポンスとともに取得キューに入れます。リクエストとレスポンスを組み合せてテスト・ケースが作成されます。 コンソールの一番下にある取得キューのステータスが更新されて、キュー内のテスト・ケースの数が反映されます。 取得キューの内容は保存することができ、「テスト」メニューのスクリプト作成コマンドまたはコマンド・ボタンを使用して、複数のテスト・ケースを含むテスト・スクリプトを作成することができます。 |
ペーパー・スクロール |
現在取得キューに置かれているあらゆるテスト・ケースを含むテスト・スクリプトを作成して、キューをクリアするかどうかの確認を行います。キューは、すべてのテスト・ケースが取得されてテスト・スクリプトに保存されるまでクリアしないでください。 |
右向きの矢印が付いたペーパー・スクロール |
現在のOAMサーバーに対してテスト・スクリプトを実行します。「ステータス」メッセージ・ウィンドウには、スクリプトが各テスト・ケースへ進むのに合わせて実行ステータスが表示されます。 |
右向きの赤い矢印が付いた地球儀 |
コピーされたURIを解析後にクリップボードからインポートし、URIパネルのフィールドに表示します。 |
疑問符 |
パスワードをクリア・テキストで表示するダイアログを表示します。 |
アクセス・テスターには表26-6に示すメニューがあります。すべてのメニュー項目にはニーモニックがあり、これはALTキーを押すことによって開くことができます(Windowsシステム上)。また、各メニュー・コマンドに対して定義されたCTRLキーと<文字キー>の組合せを使用して、コマンド・アクセラレータ(キーボード・ショートカット)を利用することもできます。
表26-6 アクセス・テスターのメニュー
メニュー名 | メニュー・コマンド |
---|---|
ファイル |
ノート: データ入力量をできるだけ少なくするために、「構成の保存」メニューと「構成を開く」メニュー(およびツールバーのコマンド・ボタン)を使用して、特定の接続、URI、およびアイデンティティ情報をファイルに保存したりファイルから読み出したりすることができます。したがって、複数構成の管理がきわめて容易になります。また、コマンド行モードでアクセス・テスターを使用してテスト・スクリプトを実行するときは、構成ファイルをアクセス・テスターへの入力として使用することができます。 |
編集 |
フィールドに対して使用できる標準編集コマンドを提供します。
|
テスト |
ノート: これらの機能を使用し、最後のリクエストと応答を取得してテスト・ケースを作成することができます。これらのテスト・ケースは、テスト・スクリプトに保存して後で実行することができます。 |
ヘルプ |
使用状況情報を表示するAboutコマンドです。 |
26.5 アクセス・テスター・コンソールによる接続性とポリシーのテスト
アクセス・テスターをOAMサーバーとともにコンソール・モードで使用して、クイック・スポット・チェックを実行できます。
エージェントとOAMサーバー間の接続のスポット・チェックやトラブルシューティングを行うと、エージェントがOAMサーバーと通信できるかどうかの評価に役立ちますが、これは、アップグレードや製品移行を行った後は特に有効です。また、エージェントやOAMサーバーによるリソース保護のスポット・チェックやトラブルシューティングを行うと、アプリケーション・ライフサイクルの間にポリシー構成のエンドツーエンド・テストを作成する際に役立ちます。
次に、実行するタスクおよびシーケンスの概要と、各タスクの詳細について参照すべき箇所を示します。
ノート:
ユーザーは、それぞれのリクエストとレスポンスのペアを取得してテスト・ケースを作成し、そのテスト・ケースをスクリプト・ファイルに保存して後で実行することができます。詳細は、「テスト・ケースおよびスクリプトの作成と管理」を参照してください。
タスクの概要: アクセス・テスター・コンソールからスポット・チェックを行う。
- 「アクセス・テスターのインストールと起動」の説明に従って、アクセス・テスターを起動します。
- 「アクセス・テスターとOAMサーバー間の接続の確立」の説明に従って、サーバー接続パネルに関連のある詳細を追加して「接続」をクリックします。
- 「アクセス・テスター・コンソールからリソース保護を検証」の説明に従って、保護リソースのURIパネルに詳細を入力またはインポートして「検証」をクリックします。
- 「アクセス・テスター・コンソールからユーザー認証をテスト」の説明に従って、ユーザー・アイデンティティ・パネルに関連のある詳細を追加して「認証」をクリックします。
- 認証が正常に終了したら、「アクセス・テスター・コンソールからユーザー認可をテスト」の説明に従ってユーザー・アイデンティティ・パネルの「認可」をクリックします。
- 「リクエスト待機時間の監視」の説明に従って、リクエストの待機時間をチェックします。
26.5.1 アクセス・テスターとOAMサーバー間の接続の確立
OAMサーバーにリクエストを送信するには、アクセス・テスターとサーバー間の通信を確立しなければなりません。
この項では、その接続を確立する方法を説明します。
26.5.1.1 アクセス・テスターのサーバー接続パネル
エミュレートしようとしているOAMサーバーとエージェントに関する必要情報をアクセス・テスターの「接続」パネルに入力して、「接続」ボタンをクリックします。テスターが接続を開始して、「ステータス・メッセージ」パネルにステータスを表示します。接続が確立されると、その接続がその後のすべての操作に使われます。
注意:
接続が確立されると、アクセス・テスター・コンソールを再起動するまでその接続を変更することはできません。
「サーバー接続」パネルとコントロールを図26-4に示します。このパネルには、OAMサーバーのプロキシ・ポートへの接続の確立に必要な情報が含まれています。
接続の確立に必要な情報を表26-7に示します。値は、Oracle Access Managementコンソールの「システム構成」タブから取得されます。
表26-7 接続パネルの情報
フィールド | 説明 |
---|---|
IPアドレス |
このテスト・セットにおけるプライマリおよびセカンダリOAMプロキシのIPアドレスをリスニングします。 ノート: 入力するのはプライムOAMプロキシの値だけにすることをお薦めします。セカンダリOAMプロキシが必要なのは、プライマリOAMサーバーとセカンダリOAMサーバー間のフェイルオーバーをテストする場合に限られます。ただし、OAP APIがプライマリOAMサーバーとセカンダリOAMサーバー間のロード・バランシングをサポートしている場合は、セカンダリ・サーバーをより実用的に利用することができます。 |
ポート |
プライマリおよびセカンダリOAMサーバーのポート番号を入力します。 |
最大接続数 |
アクセス・テスターが使用する物理的接続(TCP)ソケットの最大数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 ノート: デフォルト値の1を使用することをお薦めします。 |
最小接続数 |
アクセス・テスターが使用する物理的接続(TCP)ソケットの最小数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 ノート: デフォルト値の1を使用することをお薦めします。 |
タイムアウト |
接続の確立、あるいはOAMサーバーからのレスポンス受信のためにアクセス・テスターが待機する時間(ミリ秒)です。 ノート: デフォルト値の使用をお薦めします。 |
モード |
エミュレートするエージェントに指定された通信セキュリティのレベル。
関連項目: 「アクセス・テスターのセキュリティおよび処理について」および「証明書モードのOAMテスターのクライアント・キーストア生成」。 |
エージェントID |
テスターがシミュレートするOAMエージェントのアイデンティティを入力します。 |
エージェント・パスワード |
テスターがシミュレートするOAMエージェントのパスワードが設定されている場合は、そのパスワードを入力します。 |
疑問符 |
エージェント・パスワードの横にある「?」をクリックしてヘルプを表示します。 |
緑色のチェック・マーク |
「接続」ボタンの横の緑色のチェック・マークは、「はい」のレスポンスを示し、この場合は接続が確立されています。ステータス・メッセージ・パネルにも接続に関する「はい」のレスポンスが表示されます。 |
赤い円で囲まれたX |
「接続」ボタンの横の赤の円は、「いいえ」のレスポンスを示し、この場合、接続は存在しません。ステータス・メッセージ・パネルにも接続に関する「いいえ」のレスポンスが表示されます。 |
情報を入力して接続を確立した後は、詳細を構成ファイルに保存して後で再利用することができます。
26.5.1.2 アクセス・テスターとOAMサーバーとの接続
OAMサーバーの接続の詳細を送信できます。
26.5.2 アクセス・テスター・コンソールからリソース保護を検証
ユーザーがリソースにアクセスできるようにするには、まず、リソースが保護されていることをエージェントが確認する必要があります。
次の説明に従い、ユーザーがアクセス・テスターを使用してエージェントの役を演じ、指定されたURIが保護されているかどうかをOAMサーバーに検証させて応答をアクセス・テスターに伝達させます。
26.5.2.1 アクセス・テスターの保護リソースのURIパネル
検証しようとするリソースに関する必要情報をアクセス・テスターの「保護リソースのURI」パネルに入力し、「検証」ボタンをクリックします。
データ入力量をできるだけ小さくするために、長いURIをブラウザからコピーして、「URIのインポート」コマンド・ボタンをクリックしてインポートできます。テスターがクリップボードに保存されたURIを解析して、アクセス・テスターのURIフィールドに入力します。
リソースが保護されていることを検証するためにURI詳細を入力するパネルを図26-5に示します。これらのURIフィールドを組み合せるとRFC表記に従った書式になります。たとえば: http://oam_server1:7777/index.html
この評価を行うために必要な情報を表26-8に示します。
表26-8 保護リソースURIパネルのフィールドとコントロール
フィールドまたはコントロール | 説明 |
---|---|
スキーム |
リソースに指定された通信セキュリティに応じてhttpまたはhttpsを入力します。 ノート: アクセス・テスターはhttpまたはhttpsリソースだけをサポートします。アクセス・テスターを使用して、http以外のカスタム・リソースを保護するポリシーをテストすることはできません。 |
ホスト |
リソースの有効なホスト名を入力します。 ノート: アクセス・テスター内に指定された<host:port>の組合せは、Oracle Access Managementコンソール内に定義されたホスト識別子のいずれかと一致している必要があります。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。 |
ポート |
URIに対する有効ポートを入力します。 ノート: アクセス・テスター内に指定された<host:port>の組合せは、OAMサーバー内に定義されたようにホスト識別子のいずれかと一致する必要があります。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。 |
リソース |
URIのリソース部分を入力します(たとえば/index.htm)。このリソースは、Oracle Access Managementコンソールで認証および認可ポリシーに対して定義されたリソースと一致している必要があります。 ノート: 保護されている場合、ここに入力したリソース識別子は、Oracle Access Managementコンソールで認可ポリシーに指定された識別子と一致している必要があります。 |
赤い矢印が付いた地球儀 |
クリップボードに保存されたURIを解析してインポートするには、このボタンをクリックします。 |
操作 |
アクセス・テスターに示されたリストから、URIの操作部分を選択します。ただし、OAMサーバーはアクションの違いを認識しません。したがって、ここは「取得 」のままにしておいても問題ありません。 |
認証スキームの取得 |
保護リソースのセキュリティ保証に使用する認証スキームについて、その詳細を返すようOAMサーバーに要求するには、このチェック・ボックスを選択します。URIが保護されている場合、この情報は「ステータス・メッセージ」パネルに表示されます。 |
検証 |
「検証」ボタンをクリックしてOAMサーバーにリクエストを送信します。レスポンスを受信すると、アクセス・テスターはそのレスポンスを「ステータス・メッセージ」パネルに表示します。 |
緑色のチェック・マーク |
「検証」ボタンの横に表示される緑色のチェック・マークは、「はい」のレスポンスを示し、この場合、リソースは保護されています。ステータス・メッセージ・パネルにはリソースのリダイレクトURLが表示される他、資格証明が必要とされることも表示されます。 ノート: 「認証スキームを取得」ボックスを選択した場合は、「ステータス・メッセージ」パネルにもこのリソースを保護する認証スキームの名前とレベルが表示されます。 |
赤い円で囲まれたX |
「検証」ボタンの横に表示される赤の円は、リソースが保護されていないことを示します。「ステータス・メッセージ」パネルにも「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
26.5.2.2 リソース保護の検証
リソース情報をOAMサーバーに送信して、ステータス・メッセージ・パネルでレスポンスを検証できます。
- アクセス・テスターの「保護リソースのURI」パネルで、自身のリソース情報を入力またはインポートします(表26-8)。
- 「検証」ボタンをクリックしてリクエストを送信します。
- リソースの保護方法や保護レベルといったリソース関連のデータを含め、アクセス・テスターの出力を確認します。
- 「検証」ボタンの横に、リソースが保護されていることを示す緑色のチェック・マークが表示されていることを確認します。
- 「ステータス・メッセージ」パネルで、リダイレクトURL、認証スキーム、および資格証明が必要とされることを確認します。
- 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。
- 次のいずれかの方法を使用し、データ入力とサーバーの処理をできるだけ少なくするためにURIを保存しておきます。
- 「アクセス・テスター・コンソールからユーザー認証をテスト」に進みます。
26.5.3 アクセス・テスター・コンソールからユーザー認証をテスト
この項の内容は次のとおりです。
26.5.3.1 アクセス・テスターのユーザー・アイデンティティ・パネル
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められた認証ポリシーに基づいてユーザーのアイデンティティを検証する必要があります。アクセス・テスターを使用すれば、ユーザーがエージェントの役を演じて、保護リソースに対する特定のユーザーIDをOAMサーバーに認証させることができます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
表26-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール
フィールドまたはコントロール | 説明 |
---|---|
IPアドレス |
ユーザー資格証明の検証を行うユーザーのIPアドレスを入力します。OAMサーバーと通信するすべてのエージェントがエンド・ユーザーのIPアドレスを送信します。 デフォルト: 入力されるIPアドレスは、アクセス・テスターを実行するコンピュータに属するものです。 実際のユーザーのIPアドレスを必要とするポリシーをテストするには、デフォルトのIPアドレスを実際のIPアドレスに置き換えてください。 |
ユーザー名 |
資格証明の検証対象となる個人のユーザーIDを入力します。 ノート: 資格証明を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはそのユーザー名フィールドとパスワード・フィールドを有効または無効にします。同様に、ユーザーのX509証明書を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはその証明書フィールドを有効または無効にします。 |
パスワード |
資格証明の検証対象となる個人のパスワードを入力します。 |
? |
ポップアップ・ウィンドウ内にクリア・テキストでパスワードを表示するには、このボタンをクリックします。 |
ユーザー資格証明ストア |
資格証明を認証する必要のあるユーザーのX.509証明書を格納するPEMフォーマットのファイルです。 X509認証スキームによってURIが保護されている場合、テスターは、ユーザー名/パスワードではなく、またはユーザー名/パスワードに加えて、PEMフォーマットのX509証明書を資格証明として使用します。OAMサーバーでのセキュリティ・ポリシーの構成によっては、X509証明書が認証に使用される場合もあります。 ノート: 証明書ベースの認証を機能させるには、CA証明書とSSLキーストア証明書を使用してOAMサーバーを正しく構成する必要があります。OAMサーバーとWebゲート間の通信の保護の詳細は、「通信の保護」を参照してください。 |
... |
ユーザー証明書ストア・パスのファイル・システムを表示するには、このボタンをクリックします。 |
認証 |
OAMサーバーにリクエストを送信して「ステータス・メッセージ」パネルでレスポンスを探すには、「認証」ボタンをクリックします。 ノート: 提供される資格証明のタイプ(ユーザー名/パスワードまたはX.509証明書)は、URIを保護している認証スキームの要件と一致していなければなりません。 ノート: 証明書ベースの認証では、「通信の保護」に示すように、証明書を使用してOAMサーバー・デプロイメントを正しく構成する必要があります。 |
認可 |
ユーザーの資格証明の検証後に認可ボタンをクリックすれば、リソースに対するリクエストをOAMサーバーに送信することができます。レスポンスについては「ステータス・メッセージ」パネルを確認してください。 このリクエストは、アイデンティティ・パネルで定義されたユーザーが、「URI」パネルで定義されたリソースにアクセスできるかどうかを決定するために、「URI」およびアイデンティティ・パネルで収集した情報をOAMサーバーに送信します。サーバーは「はい」(ユーザーはリソースにアクセスできます)または「いいえ」(ユーザーはリソースにアクセスできません)を返します。OAMサーバーからは、実際のエージェントならば正常に処理するアクション(レスポンス)などの追加情報が返される場合があります。 |
緑色のチェック・マーク |
「認証」ボタンの横に表示される緑色のチェック・マークは認証が成功したことを示します。「ステータス・メッセージ」パネルにも認証が成功したことを示す「はい」のレスポンスが表示されるほか、ユーザーDNとセッションIDも示されます。 「認可」ボタンの横に表示される緑色のチェック・マークは認可が成功したことを示します。「ステータス・メッセージ」パネルにも、認可が成功したことを示す「はい」のレスポンスとアプリケーション・ドメインの詳細が表示されます。 |
赤い円で囲まれたX |
「認証」ボタンの横に表示される赤の円は認証が失敗したことを示します。「ステータス・メッセージ」パネルにも認証に失敗したことを示す「いいえ」のレスポンスが表示されます。 認可ボタンの横に表示される赤の円は認可が失敗したことを示します。「ステータス・メッセージ」パネルにも認可にしっぱししたことを示す「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
26.5.3.2 ユーザー資格証明による認証のテスト
エンド・ユーザーの資格証明をOAMサーバーに送信して、認証を検証できます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
26.5.4 アクセス・テスター・コンソールからユーザー認可をテスト
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められたポリシーに基づいてユーザーの権限を検証する必要があります。アクセス・テスターを使用してユーザーがエージェントとしての役割を演じ、認証されたユーザー・アイデンティティにリソースへのアクセスを認可できるかどうかをOAMサーバーに検証させることができます。認証されたエンド・ユーザーのリソースへのアクセス認可を検証します。このポリシー評価の際には、関係するすべての認可上の条件とレスポンスが考慮されます。
前提条件
コンソールに保持されたすべての情報でアクセス・テスター・コンソールからユーザー認証をテストします。
ノート:
アクセス・テスターから保護リソースのURIが確認されてユーザーのアイデンティティが認証されれば、それ以外の情報は必要ありません。認可ボタンをクリックしてリクエストを送信してください。ただし、リソースが別のものに変更された場合は改めてシーケンスを開始して検証を行い、次いで認証と認可を行う必要があります。
ユーザー認可のテスト方法
26.6 テスト・ケースおよびスクリプトの作成と管理
テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行う上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。
この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。
これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行うことは、ポリシー構成の質の低下を明らかにする助けとなります。
この項では、テスト管理を行うために必要な情報を次に示すトピックの中で示します。
26.6.1 テスト・ケースおよびテスト・スクリプトについて
テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。様々なデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。テスト・スクリプトは、アクセス・テスター・コンソールから構成、実行および生成できます。
取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較することができます。古い結果が「確認済(Known Good)」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。
テスト・ケースのワークフローを図26-7に示します。
タスクの概要: テスト・ケースの作成と管理
アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行うことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存することができます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行うことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。
テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド行からそのスクリプトを実行することができます。
26.6.2 テスト・ケースの取得
それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信してレスポンスを受信した後に、取得キューに保存できます。テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に、個々のテスト・ケースを必要なだけ取得できます。
例として、個別に取得する必要がある3つのテスト・ケースの概要を次に示します。
-
検証のリクエストと応答
-
認証のリクエストと応答
-
認可のリクエストと応答
表26-10に、取得オプションの場所を示します。
表26-10 アクセス・テスターの取得リクエスト・オプション
Location | 説明 |
---|---|
テスト・メニュー 最後の"..."リクエストを取得 |
「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
青色の上向き矢印 |
ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。
1つまたは複数のテスト・ケースを取得する方法
- 「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従って、アクセス・テスター・コンソールからリクエストを開始します。
- 応答を受信したら、ツール・バーの「最後の"..."リクエストを取得」コマンド・ボタンをクリックします(または「テスト」メニューから同じオプションを選択)。
- 「ステータス・メッセージ」パネルで取得を確認し、コンソールの下部に表示される取得キューのテスト・ケース数を確認します。
- ステップ1、2、3を繰り返して、テスト・スクリプトに必要な各テスト・ケースをキュー内に取得します。
- 「入力テスト・スクリプトの生成」へ進みます。
26.6.3 入力テスト・スクリプトの生成
テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアすることができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。次の各項では、さらに詳細を説明します。
ノート:
取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。
26.6.3.1 入力テスト・スクリプトについて
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。
これらのスクリプトは次の規則に従わなければなりません。
-
オペレータまたはシステムによるリプレイが可能
-
異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能
-
「確認済(Known Good)」の結果に対するテスト実行結果の比較が可能
スクリプト作成コマンドの場所を次に示します。
表26-11 スクリプト作成コマンド
コマンドの場所 | 説明 |
---|---|
テスト・メニュー スクリプトの生成 |
「テスト」メニューからスクリプト作成を選択して、取得したテスト・ケースを含むスクリプトの作成を開始します。 |
ペーパー・スクリプト・スクロール |
ツール・バーからスクリプト作成コマンド・ボタンを選択して、取得したテスト・ケースを含むスクリプトの作成を開始します。スクリプトの名前を指定または選択すると、取得キューをクリアするかどうかの確認が行われます。取得キューは、テスト・ケースがすべてスクリプトに保存されるまでクリアしないでください。 |
26.6.3.2 入力テスト・スクリプトの生成
テスト・スクリプトに含めるテスト・ケースを取得し、記録できます。
- 「テスト・ケースの取得」の説明に従って、スクリプトに含める各リクエストを実行して取得します。
- ツール・バーのスクリプト作成コマンド・ボタンをクリックして(または「テスト」メニューから同じオプションを選択して)、取得したすべてのテスト・ケースを含めます。
- 新しいダイアログ・ボックスで新しいXMLスクリプト・ファイルの名前を選択または入力し、「保存」をクリックします。
- 既存ファイルに上書きする場合は「はい」をクリックします(または「いいえ」をクリックしてウィンドウを閉じ、新しいファイル名を入力)。
- 「警告の保存」ダイアログ・ボックスで「いいえ」をクリックして取得キューをそのまま維持し、スクリプトへのテスト・ケースの追加を継続します(または「はい」をクリックしてすべてのテスト・ケースのキューをクリア)。
- アクセス・テスターを終了する前にテスト・スクリプトの場所を確認します。
- 次に示すようにスクリプトの作成者、作成時期、作成理由などの詳細を含め、テスト・スクリプトをパーソナライズします。
26.6.4 入力テスト・スクリプトのパーソナライズ
この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。
26.6.4.1 テスト・スクリプト制御パラメータ
スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使ってスクリプトをカスタマイズしたい場合もあるかもしれません。
アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンド行「制御」パラメータを使用することができます (テスト名やテスト番号など)。これにより、「確認済(Known Good)」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表26-12に示します。
表26-12 テスト・スクリプト制御パラメータ
制御パラメータ | 説明 |
---|---|
|
オリジナルのOAMサーバー応答と最新の応答を比較する際に、ユースケースの「コンテンツ」セクションの違いを無視します。デフォルトでは「コンテンツ」セクションを比較します。このパラメータは、コマンド行モードで実行するときはコマンド行プロパティで上書きすることができます。 デフォルト: false(「コンテンツ」セクションを比較) 値: trueまたはfalse コマンド行モードでは、ignorecontent=trueを使用して入力スクリプトの制御セクションの指定値を上書きしてください。 |
testname="oamtest" |
前の項に示したように、「結果バンドル」のファイル名に加える接頭辞を指定します。 コマンド行モードでは、Testname=nameを使用して「制御」セクションの指定値を上書きしてください。 |
configfile="config.xml" |
アクセス・テスターによって過去に作成された構成XMLファイルへの絶対パスを指定します。 コマンド行モードでは、このファイルは、サーバー接続を確立するための接続詳細の場所を特定するためにアクセス・テスターが使用します。 |
numthreads="1" |
複数のテスト・スクリプトのコピーを実行するために、アクセス・テスターによって開始されるスレッド(仮想クライアント)の数を示します。スレッドごとにポリシー・サーバーへの固有の接続プールが開きます。この機能はポリシー・サーバーのストレス・テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 GUIモードでテスト・スクリプトを実行する場合、スレッドの数は無視され、1つのスレッドのみが開始されてテスト・スクリプトを1回実行します。 |
numiterations="1" |
アクセス・テスターが実行する繰返し回数を示します。この機能はポリシー・サーバーのストレス・テストおよび寿命テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 |
26.6.4.2 テスト・スクリプトのカスタマイズ
アクセス・テスターで生成したテスト・スクリプトをパーソナライズできます。
- アクセス・テスターで作成したテスト・スクリプトを探して開きます。
- スクリプトをカスタマイズまたはパーソナライズするために必要な詳細を追加します。
- ファイルを保存して「テスト・スクリプトの実行」へ進みます。
26.6.5 テスト・スクリプトの実行
「確認済(Known Good)」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済」としてマークしたら、コンソールを使ってそれぞれのテストを手動で指定するのではなく、スクリプトを使ってアクセス・テスターを作動させることが重要です。
この項では次のトピックを記載しています:
26.6.5.1 テスト・スクリプトの実行について
テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行したりすることができます。
自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
ノート:
.bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。
テスト・スクリプトを実行するためのコマンドを表26-13に示します。
表26-13 テスト・スクリプト実行コマンド
Location | 説明 |
---|---|
テスト・メニュー スクリプトの実行 |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、「テスト」メニューからスクリプト実行コマンドを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
緑色の矢印が付いたペーパー・スクリプト・スクロール |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、ツール・バーからスクリプト実行コマンド・ボタンを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
コマンドライン・モード |
.bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。 |
テスト実行時のアクセス・テスターの動作について次に概要を示します。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
プロセスの概要: テスト・スクリプト実行時のアクセス・テスターの動作
-
アクセス・テスターが入力xmlファイルをロードします。
コマンド行モードでは、アクセス・テスターは入力テスト・スクリプトの「制御」要素内で定義された構成XMLファイルを開きます。
-
アクセス・テスターは、コンソールの「サーバー接続」パネル内の情報を使用してプライマリおよびセカンダリのOAMプロキシに接続します。
コマンド行モードでは、構成XMLファイル内の「接続」要素内の情報を使用します。
-
コマンド行モードでは、アクセス・テスターは入力スクリプトXMLファイルの「制御」要素をチェックして、コマンド行で上書きされたものがないことを確認します(コマンド行の値が優先されます)。
-
アクセス・テスターは、オリジナル・テスト・ケースのそれぞれについて次の処理を行います。
-
新しいターゲット・テスト・ケースを作成します。
-
OAMサーバーにオリジナル・リクエストを送信してレスポンスを収集します。
-
次の比較を行います。
新しいレスポンスとオリジナルのレスポンスを比較します。
レスポンス・コードを比較して、新しいターゲット・テスト・ケースのレスポンス・コードがオリジナル・テスト・ケースと異なる場合は、そのターゲット・テスト・ケースを「不一致(mismatched)」としてマークします。たとえば、オリジナル検証へのレスポンスが「はい」で新しい検証へのレスポンスが「いいえ」の場合は、不一致としてマークされます。
レスポンス・コードが同じで「ignorecontent」制御パラメータが「false」の場合、アクセス・テスターは「コンテンツ」を比較します(認証スキームの名前や各リクエスト後に記録される認可後のアクション)。「コンテンツ」セクションが異なる場合、新しいターゲット・テスト・ケースは「不一致」としてマークされます。
-
新しい経過時間を収集してそれをターゲット・ユースケースに保存します。
-
最後のサーバー・リクエストのすべての状態、およびオリジナル・テスト・ケースと同じ固有ID (UUID)を含む新しいターゲット・テスト・ケースを作成します。
-
ターゲット・テスト・ケースの統計値(リクエスト・タイプ、経過時間、不一致など)を使って内部統計表を更新します。
-
-
すべての入力テスト・ケースが終了すると、アクセス・テスターは次の処理を行います。
-
結果のサマリーを表示します。
-
testnameとtestnumberを取得して組み合せ、「結果バンドル」(<testname>_<testnumber>で始まる名前を持つ3つのファイル)の名前を作成します。
ノート:
テスト名とテスト番号のコマンド行パラメータを指定することにより、シェル・スクリプトを使用してバンドルの作成を自動化することができます。
コマンド行パラメータからtestnameを取得します。コマンド行で指定されていない場合は、入力スクリプトの「制御」ブロックにあるtestname要素を使用します。
コマンド行パラメータからtestnumberを取得します。指定されていない場合のtestnumberのデフォルトは、現在のローカル時刻に基づく7文字の数値文字列(分数を表す2文字、秒数を表す2文字、1/100秒を表す3文字)となります。
-
「結果バンドル」、つまり<testname>_<testnumber>で始まる名前の3つのファイルを作成します。
ターゲットXMLスクリプトには新しいテスト・ケースが格納されます: <testname>_<testnumber_results.xml
統計XMLファイルには、テスト実行全体のサマリーと詳細、および「不一致(mismatched)」とマークされたテスト・ケースが格納されます: <testname>_<testnumber_stats.xml
「ステータス・メッセージ」パネルの情報が格納される実行ログ・ファイル: <testname>_<testnumber_log.log.
-
マルチスレッド・モードで実行する場合、統計XMLファイルと実行ログ・ファイルのみが生成されます。
-
コマンド行モードでは、「アクセス・テスターのコマンド行モードについて」に示すようにアクセス・テスターは終了コードで終了します。
-
26.7 スクリプト、ログ・ファイル、および統計の評価
アクセス・テスターによって、統計ファイルがターゲット出力スクリプトおよび実行ログとともに生成されます。
この項では、次の情報について説明します。
26.7.1 テスト結果の評価について
テスト実行の終了時に生成される"結果バンドル"を使用して、テスト結果を評価できます。このバンドルは、ターゲット・スクリプト、実行ログおよび実行統計の3つのドキュメントで構成されます。
ターゲット・スクリプトとは、新しいテスト・ケースが格納されたXMLドキュメントです。オリジナル・スクリプトとターゲット・スクリプト内にあるテスト・ケースの一致ペアは、テスト・ケースIDを共有しています。このIDは、オリジナル・スクリプトとターゲット・スクリプト内の個々のテスト・ケースの比較を可能にするUUID(中略)で表されます。詳細は、「生成された入力テスト・スクリプト」を参照してください。
ノート:
アクセス・テスターがマルチスレッド・モードで実行するように構成されている場合、ターゲット・スクリプトは作成されません。
実行統計ドキュメントには、テスト・メトリック、サマリー統計と詳細統計、および一致しなかったテスト・ケースのリストが格納されます。詳細統計は、さらに詳しい分析や結果履歴の記録に使用できます。サマリー統計はテスト実行の終了時に表示されるものと同じ統計で、テスト実行の結果を迅速に評価するために使用できます。
統計ドキュメント内に作成される不一致テスト・ケースのリストには、表26-14に示すように、不一致をトリガーしたテスト・ケースIDと不一致の理由が含まれています。
表26-14 統計ドキュメントの不一致結果の理由
不一致の理由 | 説明 |
---|---|
結果 |
OAMサーバーのレスポンス・コード(「はい」と「いいえ」)が異なるためテスト・ケースが一致しませんでした。 |
コンテンツ |
OAMサーバーによって返された特定データの値が異なるためテスト・ケースが一致しませんでした。不一致をトリガーした最後のテスト実行時の特定値が含まれます。 |
26.7.2 保存された接続構成ファイル
保存された接続構成ファイルは、「ファイル」メニューの「構成を保存」コマンドを使用して保存した出力ファイルで、デフォルトのファイル名はconfig.xmlです。
この接続構成ファイルには、アクセス・テスター・コンソールのサーバー接続パネルで指定された詳細が格納されています。
ノート:
次のトピックに示すように、入力テスト・スクリプト・ファイルも作成されます。構成ファイル名は、アクセス・テスターをコマンド行モードで実行したときに接続ファイル内に定義された接続情報を取得できるようにするために、入力テスト・スクリプト内で使われます。
接続構成ファイル
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <oamtestconfig xmlns="http://xmlns.example.com/idm/oam/oamtest/schema" version="1.0"> <connection timeout="30000" minnconn="1" mode="open"> <agent password="00030d05101b050c42" name="agent1"/> <keystore rootstore="" keystore_password="" keystore="" global_passphrase=""/> <primary> <server maxconn="1" port="2100" addr="oam_server1"/> </primary> <secondary> <server maxconn="1" port="0" addr=""/> </secondary> </connection> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> <identity> <id>admin1</id> <password>00030d05101b050c42</password> <certstore></certstore> <ipaddr>111.222.3.4</ipaddr> </identity> </oamtestconfig>
26.7.3 生成された入力テスト・スクリプト
入力テスト・スクリプトは、アクセス・テスターを使用してユーザー固有のテスト・ケースを取得することによって作成されます。"Control"要素の"configfile"属性は、OAMサーバーとの接続確立用にコマンド行モードで使用する接続構成ファイルを指定するために、作成後に更新されます。
生成された入力テスト・スクリプト
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <oamtestscript xmlns="http://xmlns.example.com/idm/oam/oamtest/schema" version="1.0"> <history description="Manually generated using agent 'agent1'" createdon="2012-02-03T22:28:00.468-05:00" createdby="test_user"/> <control numthreads="1" numiterations="1" ignorecontent="false" testname="samplerun1" configfile="config.xml"/> <cases numcases="4"> <case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0"> <request code="Validate"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> </request> <response elapsed="984" code="Yes"> <comment></comment> <status>Major code: 4(ResrcOpProtected) Minor code: 2(NoCode)</status> <content> <line type="auth.scheme.id">LDAPScheme</line> <line type="auth.scheme.level">2</line> <line type="auth.scheme.required.creds">2</line> <line type="auth.scheme.redirect.url">http://emerald.uk.example.com:14100/oam/server/</line> </content> </response> </case> <case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a"> <request code="Authenticate"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> <identity> <id>weblogic</id> <password>00030d05101b050c42</password> <certstore></certstore> <ipaddr>192.168.1.8</ipaddr> </identity> </request> <response elapsed="187" code="Yes"> <comment></comment> <status>Major code: 10(CredentialsAccepted) Minor code: 2(NoCode)</status> <content> <line type="user.dn">cn=weblogic,dc=uk,dc=example,dc=com</line> </content> </response> </case> <case uuid="84fe9b06-86d1-47df-a399-6311990743c3"> <request code="Authorize"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> <identity> <id>weblogic</id> <password>00030d05101b050c42</password> <certstore></certstore> <ipaddr>192.168.1.8</ipaddr> </identity> </request> <response elapsed="188" code="Yes"> <comment></comment> <status>Major code: 8(Allow) Minor code: 2(NoCode)</status> <content/> </response> </case> <case uuid="61579e47-5532-42c3-bbc7-a00828256bf4"> <request code="Validate"> <uri getauthscheme="false"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> </request> <response elapsed="172" code="Yes"> <comment></comment> <status>Major code: 4(ResrcOpProtected) Minor code: 2(NoCode)</status> <content/> </response> </case> </cases> </oamtestscript>
26.7.4 テスト実行結果が格納されたターゲット出力ファイル
この例は、コマンド行モードでアクセス・テスターを実行して、取得した4つのテスト・ケースを実行するための入力としてscript.xmlファイルを指定することにより生成されたものです。
Dscript.scriptfile="script.xml" -jar oamtest.jar
「例: テスト実行中に生成された出力ファイル」の様々なセクションに注意してください。実行ログに示すようにこのテスト実行では不一致が見つからず、4つのリクエストのすべてが一致していることが示されています。
テスト実行中に生成された出力ファイル
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <oamtestscript xmlns="http://xmlns.example.com/idm/oam/oamtest/schema" version="1.0"> <history description="Generated from script 'script.xml' using agent 'agent1'" createdon="2012-02-03T23:03:02.171-05:00" createdby="test_user"/> <control numthreads="1" numiterations="1" ignorecontent="false" testname="oamtest" configfile=""/> <cases numcases="4"> <case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0"> <request code="Validate"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> </request> <response elapsed="969" code="Yes"> <comment></comment> <status>Major code: 4(ResrcOpProtected) Minor code: 2(NoCode)</status> <content> <line type="auth.scheme.id">LDAPScheme</line> <line type="auth.scheme.level">2</line> <line type="auth.scheme.required.creds">2</line> <line type="auth.scheme.redirect.url">http://emerald.uk.example.com:14100/oam/server/ </line> </content> </response> </case> <case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a"> <request code="Authenticate"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> <identity> <id>weblogic</id> <password>00030d05101b050c42</password> <certstore></certstore> <ipaddr>111.222.3.4</ipaddr> </identity> </request> <response elapsed="187" code="Yes"> <comment></comment> <status>Major code: 10(CredentialsAccepted) Minor code: 2(NoCode)</status> <content> <line type="user.dn">cn=weblogic,dc=us,dc=oracle,dc=com</line> </content> </response> </case> <case uuid="84fe9b06-86d1-47df-a399-6311990743c3"> <request code="Authorize"> <uri getauthscheme="true"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> <identity> <id>weblogic</id> <password>00030d05101b050c42</password> <certstore></certstore> <ipaddr>111.222.3.4</ipaddr> </identity> </request> <response elapsed="172" code="Yes"> <comment></comment> <status>Major code: 8(Allow) Minor code: 2(NoCode)</status> <content/> </response> </case> <case uuid="61579e47-5532-42c3-bbc7-a00828256bf4"> <request code="Validate"> <uri getauthscheme="false"> <scheme>http</scheme> <host>oam_server1</host> <port>7777</port> <resource>/index.html</resource> <operation>Get</operation> </uri> </request> <response elapsed="171" code="Yes"> <comment></comment> <status>Major code: 4(ResrcOpProtected) Minor code: 2(NoCode)</status> <content/> </response> </case> </cases> </oamtestscript>
26.7.5 統計ドキュメント
統計ファイル(_stats.xml)は、実行ログに示されたテスト実行時にターゲット出力スクリプトとともに作成されます。
script.xmlファイルは、取得した4つのテスト・ケースを実行するための入力として使われます。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
サンプル統計ドキュメントを「例: サンプル統計ドキュメント」に示します。この実行の統計は様々なセクションに示されており、これらと過去の「確認済(Known Good)」の統計と比較することができます。
サンプル統計ドキュメント
A sample statistics document is shown here. Notice, <oamteststats xmlns="http://xmlns.example.com/idm/oam/oamtest/schema" version="1.0"> <history description="Generated from script 'script.xml' using agent 'agent1'" createdon="2012-02-03T23:03:02.171-05:00" createdby="test_user"/> <summary> <total> <nummatched>4</nummatched> <numtotal>4</numtotal> <avgelapsedsource>238</avgelapsedsource <avgelapsedtarget>232</avgelapsedtarget> </total> <validate> <nummatched>2</nummatched> <numtotal>2</numtotal> <avgelapsedsource>578</avgelapsedsource> <avgelapsedtarget>570</avgelapsedtarget> </validate> <authenticate> <nummatched>1</nummatched> <numtotal>1</numtotal> <avgelapsedsource>187</avgelapsedsource> <avgelapsedtarget>187</avgelapsedtarget> </authenticate> <authorize> <nummatched>1</nummatched> <numtotal>1</numtotal> <avgelapsedsource>188</avgelapsedsource> <avgelapsedtarget>172</avgelapsedtarget> </authorize> <summary> <detail> <source> <validate> <yes>2</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>1156</elapsed> </validate> <authenticate> <yes>1</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>187</elapsed> </authenticate> <authorize> <yes>1</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>188</elapsed> </authorize> </source> <target> <validate> <yes>2</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>1140</elapsed> </validate> <authenticate> <yes>1</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>187</elapsed> </authenticate> <authorize> <yes>1</yes> <no>0</no> <error>0</error> <mismatch>0</mismatch> <elapsed>172</elapsed> </authorize> <target> </detail> <mismatch numcases="0"/> </oamteststats>
26.7.6 実行ログ
このサンプル実行ログは、テスト実行時に4つのテスト・ケースを実行するscript.xmlを使用して、ターゲット出力スクリプトとともに作成されたものです。
このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
この例を見ると、アクセス・テスターの「ステータス・メッセージ」パネルに表示される情報と同じ情報で構成されていることがわかります。テスト・ケース、テスト名、接続構成ファイル、エージェント名、接続ステータス、リクエスト評価ステータス、認証スキーム、リダイレクトURL、求められる資格証明、認証ステータスとユーザーDN、セッションID、認証ステータス、検証ステータス、サマリー統計などを確認してください。また、この実行によってターゲット・スクリプトと統計ドキュメントが作成されていることにも注意してください。
実行ログ
[2/3/12 11:02 PM][info] Setting up to run script 'script.xml' [2/3/12 11:02 PM][info] Loading test cases and control parameters from script [2/3/12 11:02 PM][info] Loaded 4 cases [2/3/12 11:02 PM][info] Control data for this test run: [2/3/12 11:02 PM][info] Test name : 'samplerun1' [2/3/12 11:02 PM][info] Configuration file : 'config.xml' [2/3/12 11:02 PM][info] Ignore content : 'false' [2/3/12 11:02 PM][info] Loading server configuration from file [2/3/12 11:02 PM][info] Loaded server configuration [2/3/12 11:02 PM][info] Connecting to server as agent 'oam_agent1' [2/3/12 11:03 PM][info][request] Connect : Yes ... [2/3/12 11:03 PM][info] Test 'samplerun1' will process 4 cases [2/3/12 11:03 PM][info][request] Validate : Yes [2/3/12 11:03 PM][info] Authentication scheme : LDAPScheme, level : 2 [2/3/12 11:03 PM][info] Redirect URL : http://oam_server1.uk.example.com:2100/server/ [2/3/12 11:03 PM][info] Credentials expected: 0x01 (password) [2/3/12 11:03 PM][info][request] Authenticate : Yes [2/3/12 11:03 PM][info] User DN : cn=admin1,dc=us,dc=company,dc=com [2/3/12 11:03 PM][info] Session ID : -1 [2/3/12 11:03 PM][info][request] Authorize : Yes [2/3/12 11:03 PM][info][request] Validate : Yes [2/3/12 11:03 PM][info] Summary statistics [2/3/12 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms [2/3/12 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms [2/3/12 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms [2/3/12 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms [2/3/12 11:03 PM][info] Generated target script 'samplerun1_0302171__target.xml' [2/3/12 11:03 PM][info] Generated statistics log 'samplerun1_0302171__stats.xml'