| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
Oracleでは移植可能なスタンドアロンのJavaアプリケーションであるアクセス・テスターが提供されており、このテスターはOAMサーバーに接続されている登録済エージェントをシミュレートします。スクリプトによる実行では、コマンド行処理が可能です。スクリプトを記録および再生して、様々な機能の出力を取得できます。暗号化された接続および複数のサーバー接続がサポートされています。
IT専門家や管理者はアクセス・テスターを使用して、リクエストやレスポンス・セマンティクス、アクセス・ポリシー設計の高速テストを行ったり、サーバー接続のエージェントの問題をトラブルシューティングできます。
この章では、アクセス・テスターとその使用方法を紹介します。
この章に示すタスクを実行するには、次の前提条件を満たす必要があります。
Oracle Access ManagementコンソールおよびOAMサーバーが実行中であることを確認します。
第20章の説明に従い、1つまたは複数のリソースのアプリケーション・ドメインとポリシーを確認します。
アクセス・テスターは移植可能なスタンドアロンの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サーバーに送って処理することを可能にする拡張機能を備えています。このようなテスト実行の出力はアクセス・テスターで取得し、「確認済の」応答を含む同様ドキュメントとの比較に使用することができます。このように、アクセス・テスターは、ポリシー構成の誤変更検出用の自動化テストに使用することができます。
また、アクセス・テスターには、ポリシー・サーバーのストレス・テストを実施する目的でマルチスレッド機能が提供されています。マルチスレッドによる方法では、ポリシー・サーバーに接続する仮想テスト・クライアントの数、および各仮想クライアントでテスト・スクリプトを実行する反復回数を特定します。これにより、ポリシー・サーバーのストレス・テストを実施できます。
詳細については、この章の次の説明を参照してください。
OAMアーキテクチャにおける2つの主要なアクター・タイプは、ポリシー・サーバー(OAMサーバー)とOAMポリシー強制エージェント(Webgateまたはアクセス・クライアント)です。セキュリティ分野においてはエージェントがポリシー強制点(PEP)を表し、OAMサーバーがポリシー決定点(PDP)を表します。
エージェントはhttpベース・アプリケーションなどのリソースのセキュリティを確保するゲートキーパーの役割を果たし、そのリソースにアクセスしようとするユーザーとのすべての対話操作を管理します。これは、ポリシー・サーバー(OAMサーバー)に保持されているアクセス制御ポリシーに従って実現されます。
OAMサーバーの役割は、エージェントに対してポリシー・サービス、アイデンティティ・サービス、およびセッション・サービスを提供してアプリケーション・リソースに対する適切なセキュリティを確保し、ユーザーの認証と認可を行なって、ユーザーセッションを管理することです。
この中核的なOAM製品アーキテクチャは、エージェントとOAMサーバー間の相互動作を支配する次のようなやり取りを中心に展開します。相互運用性と重要な決定点を明らかにするために、ユーザーがリソースに関するリクエストを行う際のOAMエージェントとOAMサーバー間の標準的な相互動作を図21-1に示します。
次の概要では、OAMエージェントとOAMサーバー間で行われる処理を説明します。テストの際は管理者がエンド・ユーザーの役割を果たしながら、アクセス・テスターがエージェントをエミュレートしてOAMサーバーと通信を行います。
プロセス概要: OAMエージェントとOAMサーバーの相互運用性
サーバー接続の確立: 登録OAMエージェントがOAMサーバーに接続します。
ユーザーがリソースへのアクセスをリクエストします。
リソース保護の検証: エージェントがOAMサーバーにリクエストを送って、リソースが保護されているかどうかを判断します。
保護されている場合: OAMサーバーは必要な資格証明のタイプで応答します。
ユーザー資格証明: ユーザー・アイデンティティが確立されると、監査およびSSOのための追跡とアプリケーションへの伝達が可能になります。このため、エージェントはユーザーに対して資格証明を求めます。
ユーザー資格証明の認証: エージェントは、提供されたユーザー資格証明を検証のためOAMサーバーに送ります。
認証の成功: エージェントはリソース・リクエストをOAMサーバーに送ります。
リソースへのユーザー・アクセスを認可: エージェントはまず、認可ポリシーの検証のためにOAMサーバーへアクセス・リクエストを送ることによって、リソースへのユーザーのアクセスを認めるかどうかを判定しなければなりません。
エージェントは、ポリシー応答に基づいてアクセスを認可または拒否します。
この項では、セキュアな通信、接続、保存、入力、ロギングおよび分析に関する情報を説明します。
セキュアな通信: アクセス・テスターは、OAMサーバーとの通信について、オープン接続モード、簡易接続モードまたは証明書接続モードに対応しています。
オープン・モード: 物理的接続に対するセキュリティがありません。
簡易モード: 組込み証明書を使用して物理的接続を暗号化します。簡易モードでは、OAMサーバー用に構成されたグローバル・パス・フレーズの入力を求められます。
証明書モード: フィールド提供の証明書を使用して物理的接続を暗号化します。アクセス・テスターの証明書モードでは、次を実行する必要があります。
証明書モードの通信用にエージェント(既存または新規)を構成します。
エミュレートするエージェントの証明書を取得します。
アクセス・テスターの証明書モードでは、提供されたPEM (BASE64-コード化ASCII)証明書(aaa_trust.pem、aaa_key.pem、aaa_cert.pem)からimportcertツールを使用して作成した2つのJKSキーストアが必要です。
トラスト・ストア(ルートCA証明書を持つJKSキーストアが含まれるファイル)が必要です。
キーストア(エージェントの秘密鍵および証明書を持つJKSキーストアが含まれるファイル)が必要です。
エージェント証明書を持つキーストアの暗号化には、キーストア・パスワードを使用します。
接続: アクセス・テスターは、テスターが構成ファイルとテスト・ケースに保存するすべてのパスワード型の値を暗号化します。プールに有効な接続が含まれているかどうかがアクセス・テスターで検証されます。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は出力スクリプトとともに作成されます。詳細については「実行ログについて」を参照してください。
その他の詳細については「アクセス・テスター・モードと管理者の対話操作について」を参照してください。
この項では、モード、対話操作およびアクセス・テスターの起動と実行に必要なjarファイルについて説明します。
コンソール: アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行うことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。
コマンド行およびスクリプト: アクセス・テスターでコマンド行を使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成できます。
起動および実行時JARファイル: アクセス・テスターでは、アプリケーションの起動に使用するメインjarのoamtest.jarと同じディレクトリにnap-api.jarを置く必要があります。
対話操作: アクセス・テスター実行のために選択したモードにかかわらず、ユーザーとアクセス・テスターの主な対話操作には次の操作が含まれます。
リクエストの発行と結果の表示
リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。
テスト・スクリプトの管理
テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後に何らかの自動分析を行うことができます
OAMサーバー接続の管理
サーバー接続情報を含むアプリケーション設定を管理することができます。
コンソール・モード操作とコマンド行モード操作の両方おける情報の流れを図21-2に示します。詳細は、図の後に説明します。より高度な操作としては、テスト・スクリプトの作成と実行があります。
|
注意: コマンド行モードを使用すると、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。アクセス・テスターは、読取り専用モードで使用可能な「確認済(Known Good)」の入力テスト・スクリプトを変更せずにテスト実行を構成する制御メカニズムを公開しています。 |
テスター・コンソール・モード操作とコマンド行モード操作の両方における情報の処理フローを表21-1に示します。
表21-1 ユーザー操作: テスター・コンソール・モードとコマンド行モードの操作
| テスター・コンソール・モード | コマンド行モード |
|---|---|
|
ユーザーはコマンド行からアクセス・テスターを開始します。 |
コマンド行モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。 セキュアな通信用の証明書モード: キーストアは、以前に保存された構成情報が格納されているOamTestConfiguration.xmlファイルで指定されます。 |
|
ユーザーが前に保存されたOamTestConfiguration.xmlファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、テスター・コンソールを使用して手動でデータを入力することもできます。 |
アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。 |
|
ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。 |
入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。 |
|
リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。 |
リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。 |
|
アクセス・テスターはテスト完了時に次のものを作成します。
|
アクセス・テスターはスクリプト完了時に次のものを作成します。
|
|
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
|
証明書モードでは、必要なキーストアを特定するように要求されます。 |
証明書モードでは、キーストアは、以前に保存された構成情報が格納されているXMLファイルで指定されます。 |
以下ではアクセス・テスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。
タスクの概要: Access Managerの接続とポリシーのテスト
次のトピックを確認します。
「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行してデータを取り込みます。
「テスト・ケースおよびスクリプトの作成と管理」へ進みます。
アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できる2つのjarファイルで構成されます。この項では、テストを実行するコンピュータにアクセス・テスターのjarファイルをコピーするなど、アクセス・テスターのインストール方法を説明します。テスト入力用に選択したモードがテスター・コンソール・モードかコマンド行モードかにかかわらず、アクセス・テスターはコマンド行から開始する必要があります。この項は次のトピックに分かれています:
このトピックでは、どのコンピュータでも使えるようにアクセス・テスターをインストールする方法を説明します。インストール終後は、いつでもアクセス・テスターを使用することができます。特別なセットアップは必要ありません。
アクセス・テスターのインストール方法
テスターを実行するコンピュータにJDK/JRE 6が含まれていることを確認します。たとえば、次のようにJavaをテストすることができます。
java -version
前述のコマンドは次に示す情報を返します。
java version "1.6.0_18" Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)
OAMサーバーをホストしているコンピュータ上で、アクセス・テスターのJarファイルを探してコピーします。例:
$ORACLE_HOME/oam/server/tester/oamtest.jar $ORACLE_HOME/oam/server/tester/nap-api.jar
アクセス・テスターを実行しようとするコンピュータ上の同じディレクトリ内に、jarファイルのコピーを保存します。
証明書モード: OAMサーバーの通信モードが「証明書」の場合、アクセス・テスターを実行するコンピュータに、Oracle Access Managementコンソールのエージェント登録ページで定義されているものと同じキーストアが含まれていることを確認してください。「第15章」を参照してください。
使用する環境と要件に応じて、次の手順に従ってください。
テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始するの手順に従えば、手動でリクエストを実行できます。
テスト・スクリプトの実行の手順に従えば、「確認済(Known Good)」のポリシー構成に従って作成され、「確認済」としてマークされたテスト・スクリプトを使用することができます。
アクセス・テスターでは、プレゼンテーションに使用したりテストの特定側面に使用したりすることのできるいくつかの構成オプションを選択することができます。これらのオプションは、サポートされているすべてのシステム・プロパティを示した表21-2に示すように、起動時にJavaの-Dメカニズムを使用して指定します。
表21-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" |
グラフィカル・ユーザー・インタフェースを通じて手動でリクエストを行って(結果を取り込み)リアルタイム応答を表示するには、テスター・コンソール・モードでテスターを開始します。テスター・コンソール・モードでもいくつかのシステム・プロパティを使用できますが、この手順ではすべて省略します。
jarファイルはデフォルトの開始クラスを定義します(クラス名を指定する必要はありません)。oamtest.jarと同じディレクトリ内にnap-api.jarが存在することを確認してください。
システム・プロパティを使わずにコンソール・モードでシステム・テスターを開始する方法
アクセス・テスターのjarファイルが置かれたディレクトリで、次のコマンドを入力します。
java -jar oamtest.jar
oamtestコマンド行ツールで使用可能なすべてのオプションを一覧表示するには、-helpオプションを使用します。
java -jar oamtest.jar -help
詳細については次のいずれかのトピックを参照してください。
この項は次のトピックに分かれています:
テスト・スクリプトを実行したりアクセス・テスターの動作をカスタマイズしたりするには、コマンド行モードでテスターを開始し、Javaの-Dオプションを使ってシステム・プロパティを含めなければなりません。
コマンド行モードでアクセス・テスターを実行すると、アクセス・テスターは、テスト実行管理のためのシェル・スクリプトで使用できる完了コードを返します。コンソール・モードでアクセス・テスターを実行するときは、アクセス・テスターによって返されるコードに従う必要はありません。
特定のテスト・ケースを実行するためにアクセス・テスターをラップするシェル・スクリプトは、アクセス・テスターによって伝達される終了コードを認識し、これに従って動作できる必要があります。コマンド行モードでは、アクセス・テスターはSystem.Exit (N)を使用して終了します(Nは次のいずれかのコードになります)。
0は、不一致なしですべてのテスト・ケースが正常に終了したことを示します。これには、入力スクリプト内にテスト・ケースが定義されていない状況も含まれます。
3は、少なくとも1つの不一致ですべてのテスト・ケースが正常に終了したことを示します。
1は、エラーによってアクセス・テスターを実行できなかったこと、またはテスト・ケースを完了できなかったことを示します。これには、入力スクリプトが指定されていない、入力スクリプトを読み込めない、サーバー接続を確立できない、ターゲット・スクリプトを作成できないという状態が含まれます。
これらの終了コードは、アクセス・テスターを使って特定のテスト・ケースを実行するために作られたシェル・スクリプト(Bourneシェルの$?)によって取得することができます。
次の手順を使ってコマンド行モードでアクセス・テスターを開始し、Javaの-Dメカニズムを使用して任意の数の構成オプションを指定します。
システム・プロパティを指定してアクセス・テスターを開始する方法、またはコマンド行モードで開始する方法
アクセス・テスターのjarファイルが置かれたディレクトリで、使用環境に合った適切なシステム・プロパティを指定してコマンドを入力します。例:
java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true" -jar oamtest.jar
開始後は、次のいずれかのトピックを参照してください。
この項では、アクセス・テスター・コンソール、ナビゲーション、およびコントロールの概要を示します。
固定サイズのアクセス・テスター・コンソールを図21-3に示します。コンソール・モードでアクセス・テスターを開始した場合、ユーザーはこのウィンドウを通じてアプリケーションとの対話操作を行うことができます。このウィンドウのサイズを変更することはできません。詳細は、図の後に説明します。
メイン・ウィンドウの最上部にあるメニュー・バーにはメニュー名が表示されています。メニュー・バーの下にはツール・バーがあります。ツール・バー内にボタンで表示されているすべてのコマンドは、メニュー・コマンドとして選択することもできます。アクセス・テスター・コンソールは、表21-3に示すように4つのパネルに分割されています。
表21-3 アクセス・テスターのコンソール・パネル
| パネル名 | 説明 |
|---|---|
|
サーバー接続 |
OAMサーバー(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)との接続を確立するために必要な情報を入力するためのフィールドと、「接続」ボタンがあります。 「アクセス・テスターとOAMサーバー間の接続の確立」も参照してください。 |
|
保護リソースのURI |
保護状態を検証する必要のあるリソースに関する情報が表示されます。リソース検証サーバー・リクエストを送信するには、「検証」ボタンを使用します。 「アクセス・テスター・コンソールからリソース保護を検証」も参照してください。 |
|
ユーザー・アイデンティティ |
資格証明を認証する必要のあるユーザーに関する情報が表示されます。「ユーザーの認証」サーバー・リクエストの送信には「認証」ボタンを使用します。 「アクセス・テスター・コンソールからユーザー認証をテスト」も参照してください。 |
|
ステータス・メッセージ |
ユーザーのリクエストに対してアプリケーションが表示するメッセージで構成された、スクロール可能なステータス・メッセージ・エリアが表示されます。「ユーザーの認可」サーバー・リクエストの送信には認可ボタンを使用します。 「リクエスト待機時間の監視」も参照してください。 |
テキスト・フィールドでは、右クリックによる「編集」メニューの表示、およびマウスとカーソルによるドラッグアンドドロップ操作が可能です。
OAMサーバーにテスト・リクエストを送信するために使用する4つのプライマリ・ボタンがあります。それぞれのボタンは、表21-4に示す指定アクションを開始するためのトリガーとして働きます。
表21-4 アクセス・テスター・パネルのコマンド・ボタン
| パネル・ボタン | 説明 |
|---|---|
|
接続 |
接続情報を送信して接続を開始します。 |
|
検証 |
「保護リソースのURI」パネルに入力された情報を送信して、保護の検証を開始します。 |
|
認証 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認証の確認を開始します。 |
|
認可 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認可の確認を開始します。 |
アクセス・テスターのその他のボタンとその使用方法を表21-5に示します。ボタンの上にカーソルを合わせると、そのボタンに関するヒントが表示されます。
表21-5 その他のアクセス・テスター・ボタン
| コマンド・ボタン | 説明 |
|---|---|
 |
XMLファイル(デフォルトはconfig.xml)に保存された接続構成の詳細をロードします。 このボタンをクリックすると、コンソール内の情報をリフレッシュすることができます。 |
 |
接続構成の詳細をファイル(デフォルト名はconfig.xml)に保存します。このドキュメントの名前は、コマンド行モードで実行中のアクセス・テスターに正しい接続情報を提供するために、入力スクリプトに追加できます。 コンソールの一番下にある「保存」コマンド・ボタンは、「ステータス・メッセージ」パネルの内容をログ・ファイルに保存します。 |
 |
アイコンを含むパネル上のフィールドをクリアします。ツール・バーのボタンを使用すると、接続がすでに確立されている場合は接続フィールドを除くすべてのフィールドがクリアされます。 |
 |
最後に指定されたリクエストを取得し、これに対してOAMサーバーから受信したレスポンスとともに取得キューに入れます。リクエストとレスポンスを組み合せてテスト・ケースが作成されます。 コンソールの一番下にある取得キューのステータスが更新されて、キュー内のテスト・ケースの数が反映されます。 取得キューの内容は保存することができ、「テスト」メニューのスクリプト作成コマンドまたはコマンド・ボタンを使用して、複数のテスト・ケースを含むテスト・スクリプトを作成することができます。 |
 |
現在取得キューに置かれているあらゆるテスト・ケースを含むテスト・スクリプトを作成して、キューをクリアするかどうかの確認を行います。キューは、すべてのテスト・ケースが取得されてテスト・スクリプトに保存されるまでクリアしないでください。 |
 |
現在のOAMサーバーに対してテスト・スクリプトを実行します。「ステータス」メッセージ・ウィンドウには、スクリプトが各テスト・ケースへ進むのに合わせて実行ステータスが表示されます。 |
 |
コピーされたURIを解析後にクリップボードからインポートし、URIパネルのフィールドに表示します。 |
 |
パスワードをクリア・テキストで表示するダイアログを表示します。 |
アクセス・テスターには表21-6に示すメニューがあります。すべてのメニュー項目にはニーモニックがあり、これはALTキーを押すことによって開くことができます(Windowsシステム上)。また、各メニュー・コマンドに対して定義されたCTRLキーと<文字キー>の組合せを使用して、コマンド・アクセラレータ(キーボード・ショートカット)を利用することもできます。
表21-6 アクセス・テスターのメニュー
| メニュー名 | メニュー・コマンド |
|---|---|
|
ファイル |
注: データ入力量をできるだけ少なくするために、「構成の保存」メニューと「構成を開く」メニュー(およびツールバーのコマンド・ボタン)を使用して、特定の接続、URI、およびアイデンティティ情報をファイルに保存したりファイルから読み出したりすることができます。したがって、複数構成の管理がきわめて容易になります。また、コマンド行モードでアクセス・テスターを使用してテスト・スクリプトを実行するときは、構成ファイルをアクセス・テスターへの入力として使用することができます。 |
|
編集 |
フィールドに対して使用できる標準編集コマンドを提供します。
|
|
テスト |
注: これらの機能を使用し、最後のリクエストと応答を取得してテスト・ケースを作成することができます。これらのテスト・ケースは、テスト・スクリプトに保存して後で実行することができます。 |
|
ヘルプ |
使用状況情報を表示するAboutコマンドです。 |
この項では、アクセス・テスターをOAMサーバーとともにコンソール・モードで使用して、クイック・スポット・チェックを行う方法を説明します。
エージェントとOAMサーバー間の接続のスポット・チェックやトラブルシューティングを行うと、エージェントがOAMサーバーと通信できるかどうかの評価に役立ちますが、これは、アップグレードや製品移行を行った後は特に有効です。また、エージェントやOAMサーバーによるリソース保護のスポット・チェックやトラブルシューティングを行うと、アプリケーション・ライフサイクルの間にポリシー構成のエンドツーエンド・テストを作成する際に役立ちます。
次に、実行するタスクおよびシーケンスの概要と、各タスクの詳細について参照すべき箇所を示します。
|
注意: ユーザーは、それぞれのリクエストとレスポンスのペアを取得してテスト・ケースを作成し、そのテスト・ケースをスクリプト・ファイルに保存して後で実行することができます。詳細については「テスト・ケースおよびスクリプトの作成と管理」を参照してください。 |
タスクの概要: アクセス・テスター・コンソールからスポット・チェックを行う。
「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。
「アクセス・テスターとOAMサーバー間の接続の確立」の説明に従って、「サーバー接続」パネルに関連詳細事項を入力します。
「アクセス・テスター・コンソールからリソース保護を検証」の説明に従って、「保護リソースのURI」ペインに詳細を入力またはインポートします。
「アクセス・テスター・コンソールからユーザー認証をテスト」の説明に従って、「ユーザー・アイデンティティ」パネルに関連詳細事項を入力します。
認証が正常に終了したら、「アクセス・テスター・コンソールからユーザー認可をテスト」の説明に従って「ユーザー・アイデンティティ」パネルの認可をクリックします。
「リクエスト待機時間の監視」の説明に従って、リクエストの待機時間をチェックします。
OAMサーバーにリクエストを送信するには、アクセス・テスターとサーバー間の通信を確立しなければなりません。この項では、その接続を確立する方法を説明します。
エミュレートしようとしているOAMサーバーとエージェントに関する必要情報をアクセス・テスターの「接続」パネルに入力して、「接続」ボタンをクリックします。テスターが接続を開始して、「ステータス・メッセージ」パネルにステータスを表示します。接続が確立されると、その接続がその後のすべての操作に使われます。
|
注意: 接続が確立されると、アクセス・テスター・コンソールを再起動するまでその接続を変更することはできません。 |
「サーバー接続」パネルとコントロールを図21-4に示します。このパネルには、OAMサーバーのプロキシ・ポートへの接続の確立に必要な情報が含まれています。
接続の確立に必要な情報を表21-7に示します。この値は、Oracle Access Managementコンソールの「システム構成」タブから取得されます。
表21-7 接続パネルの情報
| フィールド | 説明 |
|---|---|
|
IPアドレス |
このテスト・セットにおけるプライマリおよびセカンダリOAMプロキシのIPアドレスをリスニングします。 注: 入力するのはプライムOAMプロキシの値だけにすることをお薦めします。セカンダリOAMプロキシが必要なのは、プライマリOAMサーバーとセカンダリOAMサーバー間のフェイルオーバーをテストする場合に限られます。ただし、OAP APIがプライマリOAMサーバーとセカンダリOAMサーバー間のロード・バランシングをサポートしている場合は、セカンダリ・サーバーをより実用的に利用することができます。 |
|
ポート |
プライマリおよびセカンダリOAMサーバーのポート番号を入力します。 |
|
最大接続数 |
アクセス・テスターが使用する物理的接続(TCP)ソケットの最大数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 注: デフォルト値の1を使用することをお薦めします。 |
|
最小接続数 |
アクセス・テスターが使用する物理的接続(TCP)ソケットの最小数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 注: デフォルト値の1を使用することをお薦めします。 |
|
タイムアウト |
接続の確立、あるいはOAMサーバーからのレスポンス受信のためにアクセス・テスターが待機する時間(ミリ秒)です。 注: デフォルト値の使用をお薦めします。 |
|
モード |
エミュレートするエージェントに指定された通信セキュリティのレベル。
関連項目: 「アクセス・テスターのセキュリティと処理について」および「証明書モードのOAMテスターのクライアント・キーストア生成」 |
|
エージェントID |
テスターがシミュレートするOAMエージェントのアイデンティティを入力します。 |
|
エージェント・パスワード |
テスターがシミュレートするOAMエージェントのパスワードが設定されている場合は、そのパスワードを入力します。 |
 |
エージェント・パスワードの横にある「?」をクリックしてヘルプを表示します。 |
 |
「接続」ボタンの横の緑色のチェック・マークは、「はい」のレスポンスを示し、この場合は接続が確立されています。ステータス・メッセージ・パネルにも接続に関する「はい」のレスポンスが表示されます。 |
 |
「接続」ボタンの横の赤の円は、「いいえ」のレスポンスを示し、この場合、接続は存在しません。ステータス・メッセージ・パネルにも接続に関する「いいえ」のレスポンスが表示されます。 |
情報を入力して接続を確立した後は、詳細を構成ファイルに保存して後で再利用することができます。
次の手順を使用してOAMサーバーの接続の詳細を送信します。
前提条件
アクセス・テスターとOAMサーバー間の接続のテスト方法
「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。
「サーバー接続」パネル(表21-7)で、次の情報を入力します。
プライマリおよびセカンダリOAMプロキシの詳細
タイムアウト時間
通信暗号化モード
エージェントの詳細
「接続」ボタンをクリックします。
「接続」ボタンの横に、接続の確立を示す緑色のチェック・マークが表示されていることを確認します。
「ステータス・メッセージ」パネルに「はい」のレスポンスが表示されていることを確認します。
成功しない場合: OAMサーバーへの接続に問題がある場合は、すべての接続情報(必要に応じて、IPアドレスとポート、エージェント名とパスワード、接続モードおよび関連する証明書とパスワード)を正しく入力したことを確認してください。
まだ接続を確立できない場合は、トレース接続コマンド・モードを使用してアクセス・テスター・コンソールを起動し、接続ログ内の詳細を確認します。また、OAMサーバーの管理者にポリシー・サーバー・ログの確認を依頼します。
ユーザーがリソースにアクセスできるようにするには、まず、リソースが保護されていることをエージェントが確認する必要があります。次の説明に従い、ユーザーがアクセス・テスターを使用してエージェントの役を演じ、指定されたURIが保護されているかどうかをOAMサーバーに検証させて応答をアクセス・テスターに伝達させます。
検証しようとするリソースに関する必要情報をアクセス・テスターの「保護リソースのURI」パネルに入力し、「検証」ボタンをクリックします。
データ入力量をできるだけ小さくするために、長いURIをブラウザからコピーして、「URIのインポート」コマンド・ボタンをクリックしてインポートできます。テスターがクリップボードに保存されたURIを解析して、アクセス・テスターのURIフィールドに入力します。
リソースが保護されていることを検証するためにURI詳細を入力するパネルを図21-5に示します。これらのURIフィールドを組み合せるとRFC表記に従った書式になります。例: http://oam_server1:7777/index.html
この評価を行うために必要な情報を表21-8に示します。
表21-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が表示される他、資格証明が必要とされることも表示されます。 注: 「認証スキームを取得」ボックスを選択した場合は、「ステータス・メッセージ」パネルにもこのリソースを保護する認証スキームの名前とレベルが表示されます。 |
|
「検証」ボタンの横に表示される赤の円は、リソースが保護されていないことを示します。「ステータス・メッセージ」パネルにも「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
次の手順を使用してリソース情報をOAMサーバーに送信し、「ステータス・メッセージ」パネルでレスポンスを検証します。
前提条件
リソースが保護されていることを確認する方法
アクセス・テスターの「保護リソースのURI」パネルで、自身のリソース情報を入力またはインポートします(表21-8)。
「検証」ボタンをクリックしてリクエストを送信します。
リソースの保護方法や保護レベルといったリソース関連のデータを含め、アクセス・テスターの出力を確認します。
「検証」ボタンの横に、リソースが保護されていることを示す緑色のチェック・マークが表示されていることを確認します。
「ステータス・メッセージ」パネルで、リダイレクトURL、認証スキーム、および資格証明が必要とされることを確認します。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。
次のいずれかの方法を使用し、データ入力とサーバーの処理をできるだけ少なくするためにURIを保存しておきます。
「アクセス・テスター・コンソールからユーザー認証をテスト」に進んでください。
この項の内容は次のとおりです。
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められた認証ポリシーに基づいてユーザーのアイデンティティを検証する必要があります。アクセス・テスターを使用すれば、ユーザーがエージェントの役を演じて、保護リソースに対する特定のユーザーIDをOAMサーバーに認証させることができます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
テスト評価に必要な情報を入力するアクセス・テスター・パネルを図21-6 に示します。
入力が必要な情報を表21-9に示します。
表21-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール
| フィールドまたはコントロール | 説明 |
|---|---|
|
IPアドレス |
ユーザー資格証明の検証を行うユーザーのIPアドレスを入力します。OAMサーバーと通信するすべてのエージェントがエンド・ユーザーのIPアドレスを送信します。 デフォルト: 入力されるIPアドレスは、アクセス・テスターを実行するコンピュータに属するものです。 実際のユーザーのIPアドレスを必要とするポリシーをテストするには、デフォルトのIPアドレスを実際のIPアドレスに置き換えてください。 |
|
ユーザー名 |
資格証明の検証対象となる個人のユーザーIDを入力します。 注意: 資格証明を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはそのユーザー名フィールドとパスワード・フィールドを有効または無効にします。同様に、ユーザーのX509証明書を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはその証明書フィールドを有効または無効にします。 |
|
パスワード |
資格証明の検証対象となる個人のパスワードを入力します。 |
|
? |
ポップアップ・ウィンドウ内にクリア・テキストでパスワードを表示するには、このボタンをクリックします。 |
|
ユーザー資格証明ストア |
資格証明を認証する必要のあるユーザーのX.509証明書を格納するPEMフォーマットのファイルです。 X509認証スキームによってURIが保護されている場合、テスターは、ユーザー名/パスワードではなく、またはユーザー名/パスワードに加えて、PEMフォーマットのX509証明書を資格証明として使用します。OAMサーバーでのセキュリティ・ポリシーの構成によっては、X509証明書が認証に使用される場合もあります。 注意: 証明書ベースの認証を機能させるには、CA証明書とSSLキーストア証明書を使用してOAMサーバーを正しく構成する必要があります。OAMサーバーとWebgate間の通信のセキュリティ確保の詳細は、付録Cを参照してください。 |
|
... |
ユーザー証明書ストア・パスのファイル・システムを表示するには、このボタンをクリックします。 |
|
認証 |
OAMサーバーにリクエストを送信して「ステータス・メッセージ」パネルでレスポンスを探すには、「認証」ボタンをクリックします。 注意: 提供される資格証明のタイプ(ユーザー名/パスワードまたはX.509証明書)は、URIを保護している認証スキームの要件と一致していなければなりません。 注意: 証明書ベースの認証では、付録Cに示すように、証明書を使用してOAMサーバー・デプロイメントを正しく構成する必要があります。 |
|
認可 |
ユーザーの資格証明の検証後に認可ボタンをクリックすれば、リソースに対するリクエストをOAMサーバーに送信することができます。レスポンスについては「ステータス・メッセージ」パネルを確認してください。 このリクエストは、アイデンティティ・パネルで定義されたユーザーが、「URI」パネルで定義されたリソースにアクセスできるかどうかを決定するために、「URI」およびアイデンティティ・パネルで収集した情報をOAMサーバーに送信します。サーバーは「はい」(ユーザーはリソースにアクセスできます)または「いいえ」(ユーザーはリソースにアクセスできません)を返します。OAMサーバーからは、実際のエージェントならば正常に処理するアクション(レスポンス)などの追加情報が返される場合があります。 |
|
「認証」ボタンの横に表示される緑色のチェック・マークは認証が成功したことを示します。「ステータス・メッセージ」パネルにも認証が成功したことを示す「はい」のレスポンスが表示されるほか、ユーザーDNとセッションIDも示されます。 「認可」ボタンの横に表示される緑色のチェック・マークは認可が成功したことを示します。「ステータス・メッセージ」パネルにも、認可が成功したことを示す「はい」のレスポンスとアプリケーション・ドメインの詳細が表示されます。 |
|
「認証」ボタンの横に表示される赤の円は認証が失敗したことを示します。「ステータス・メッセージ」パネルにも認証に失敗したことを示す「いいえ」のレスポンスが表示されます。 認可ボタンの横に表示される赤の円は認可が失敗したことを示します。「ステータス・メッセージ」パネルにも認可にしっぱししたことを示す「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
次の手順を使用してエンド・ユーザーの資格証明をOAMサーバーに送信し、認証を検証します。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
前提条件
コンソールに保持されたURI情報でアクセス・テスター・コンソールからリソース保護を検証します。
ユーザー資格証明による認証のテスト方法
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認証対象のユーザーに関する情報を入力します(表21-9)。
「認証」ボタンをクリックしてリクエストを送信します。
「認証」ボタンの横に、ユーザーが認証されたことを示す緑色のチェック・マークが表示されていることを確認します。
認証できない場合: 正しいユーザーIDとパスワードを入力したことを確認し、再度認証を試みてください。また、第17章の説明に従い、終了させる必要のあるアクティブ・ユーザー・セッションの有無をOracle Access Managementコンソールで確認してください。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。
URIとユーザー・アイデンティティ情報を保持して、「アクセス・テスター・コンソールからユーザー認可をテスト」へ進んでください。
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められたポリシーに基づいてユーザーの権限を検証する必要があります。アクセス・テスターを使用してユーザーがエージェントとしての役割を演じ、認証されたユーザー・アイデンティティにリソースへのアクセスを認可できるかどうかをOAMサーバーに検証させることができます。
次の手順を使用して、認証済エンド・ユーザーのリソースへのアクセス認可を検証します。このポリシー評価の際には、関係するすべての認可上の条件とレスポンスが考慮されます。
前提条件
コンソールに保持されたすべての情報でアクセス・テスター・コンソールからユーザー認証をテストします。
|
注意: アクセス・テスターから保護リソースのURIが確認されてユーザーのアイデンティティが認証されれば、それ以外の情報は必要ありません。認可ボタンをクリックしてリクエストを送信してください。ただし、リソースが別のものに変更された場合は改めてシーケンスを開始して検証を行い、次いで認証と認可を行う必要があります。 |
ユーザー認可のテスト方法
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、ユーザーが認証されていることを確認します(表21-9)。
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認可ボタンをクリックします。
認可ボタンの横に、ユーザーが認可されたことを示す緑色のチェック・マークが表示されていることを確認します。
成功しない場合: Oracle Access Managementコンソールを使用して認可ポリシーを確認します。
「ステータス・メッセージ」パネルで、テスト実行に関する詳細を確認します。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。
次の項目へ進みます。
OAMサーバーのパフォーマンスを理解するには、OAMサーバーがエージェントから渡されるリクエストをどの程度の効率で処理しているかを知る必要があります。サーバーのメトリックを明らかにする方法は数多くありますが、エージェントの立場からサーバーのパフォーマンスを明らかにするのが有効な場合もあります。これは、アクセス・テスターを使用して次の手順により行うことができます。
前提条件
タスクの概要: リクエスト待機時間の監視には次のタスクが含まれます。
次に示す実行ログファイル内、およびテスト実行中に生成されるその他のファイル内の待機時間情報を確認します。例:
... [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 ...
次の項目へ進みます。
テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行う上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。
これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行うことは、ポリシー構成の質の低下を明らかにする助けとなります。
この項では、テスト管理を行うために必要な情報を次に示すトピックの中で示します。
テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。様々なデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。
取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較することができます。古い結果が「確認済(Known Good)」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。
テスト・ケースのワークフローを図21-7に示します。
タスクの概要: テスト・ケースの作成と管理
アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行うことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存することができます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行うことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。
テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド行からそのスクリプトを実行することができます。
それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信してレスポンスを受信した後に、取得キューに保存できます。テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に、個々のテスト・ケースを必要なだけ取得できます。例として、個別に取得する必要がある3つのテスト・ケースの概要を次に示します。
検証のリクエストと応答
認証のリクエストと応答
認可のリクエストと応答
表21-10に、取得オプションの場所を示します。
表21-10 アクセス・テスターの取得リクエスト・オプション
| ロケーション | 説明 |
|---|---|
|
「テスト」メニュー 最後の"..."リクエストを取得 |
「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
|
ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。
1つまたは複数のテスト・ケースを取得する方法
「アクセス・テスター・コンソールからの接続性とポリシーのテスト」の説明に従い、アクセス・テスターからリクエストを発行します。
応答を受信したら、ツール・バーの「最後の"..."リクエストを取得」コマンド・ボタンをクリックします(または「テスト」メニューから同じオプションを選択)。
「ステータス・メッセージ」パネルで取得を確認し、さらにコンソールの一番下に表示される取得キューのテスト・ケース数を確認します。
ステップ1、2、3を繰り返して、テスト・スクリプトに必要な各テスト・ケースをキュー内に取得します。
「入力テスト・スクリプトの作成」へ進みます。
テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアすることができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。
|
注意: 取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。 |
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。これらのスクリプトは次の規則に従わなければなりません。
オペレータまたはシステムによるリプレイが可能
異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能
「確認済(Known Good)」の結果に対するテスト実行結果の比較が可能
スクリプト作成コマンドの場所を次に示します。
前提条件
取得したテスト・ケースを含むテスト・スクリプトの作成方法
「テスト・ケースの取得」の説明に従い、スクリプトに含めたいリクエストを実行して取得します。
ツール・バーのスクリプト作成コマンド・ボタンをクリックして(または「テスト」メニューから同じオプションを選択して)、取得したすべてのテスト・ケースを含めます。
新しいダイアログ・ボックスで新しいXMLスクリプト・ファイルの名前を選択または入力し、「保存」をクリックします。
既存ファイルに上書きする場合は「はい」をクリックします(または「いいえ」をクリックしてウィンドウを閉じ、新しいファイル名を入力)。
「警告の保存」ダイアログ・ボックスで「いいえ」をクリックして取得キューをそのまま維持し、スクリプトへのテスト・ケースの追加を継続します(または「はい」をクリックしてすべてのテスト・ケースのキューをクリア)。
アクセス・テスターを終了する前にテスト・スクリプトの場所を確認します。
次に示すようにスクリプトの作成者、作成時期、作成理由などの詳細を含め、テスト・スクリプトをパーソナライズします。
この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。
スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使ってスクリプトをカスタマイズしたい場合もあるかもしれません。
アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンド行「制御」パラメータを使用することができます (テスト名やテスト番号など)。これにより、「確認済(Known Good)」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表21-12に示します。
表21-12 テスト・スクリプト制御パラメータ
| 制御パラメータ | 説明 |
|---|---|
|
|
オリジナルのOAMサーバー応答と最新の応答を比較する際に、ユースケースの「コンテンツ」セクションの違いを無視します。デフォルトでは「コンテンツ」セクションを比較します。このパラメータは、コマンド行モードで実行するときはコマンド行プロパティで上書きすることができます。 デフォルト: false(「コンテンツ」セクションを比較) 値: trueまたはfalse コマンド行モードでは、ignorecontent=trueを使用して入力スクリプトの制御セクションの指定値を上書きしてください。 |
|
testname="oamtest" |
前の項に示したように、「結果バンドル」のファイル名に加える接頭辞を指定します。 コマンド行モードでは、Testname=nameを使用して「制御」セクションの指定値を上書きしてください。 |
|
configfile="config.xml" |
アクセス・テスターによって過去に作成された構成XMLファイルへの絶対パスを指定します。 コマンド行モードでは、このファイルは、サーバー接続を確立するための接続詳細の場所を特定するためにアクセス・テスターが使用します。 |
|
numthreads="1" |
複数のテスト・スクリプトのコピーを実行するために、アクセス・テスターによって開始されるスレッド(仮想クライアント)の数を示します。スレッドごとにポリシー・サーバーへの固有の接続プールが開きます。この機能はポリシー・サーバーのストレス・テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 GUIモードでテスト・スクリプトを実行する場合、スレッドの数は無視され、1つのスレッドのみが開始されてテスト・スクリプトを1回実行します。 |
|
numiterations="1" |
アクセス・テスターが実行する繰返し回数を示します。この機能はポリシー・サーバーのストレス・テストおよび寿命テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 |
前提条件
テスト・スクリプトのカスタマイズ方法
アクセス・テスターで作成したテスト・スクリプトを探して開きます。
スクリプトをカスタマイズまたはパーソナライズするために必要な詳細を追加します。
ファイルを保存して「テスト・スクリプトの実行」へ進みます。
「確認済(Known Good)」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済」としてマークしたら、コンソールを使ってそれぞれのテストを手動で指定するのではなく、スクリプトを使ってアクセス・テスターを作動させることが重要です。この項では次のトピックを記載しています:
テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行したりすることができます。自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
|
注意: .bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。 |
テスト・スクリプトを実行するためのコマンドを表21-13に示します。
表21-13 テスト・スクリプト実行コマンド
| ロケーション | 説明 |
|---|---|
|
「テスト」メニュー スクリプト実行 |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、「テスト」メニューからスクリプト実行コマンドを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
|
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、ツール・バーからスクリプト実行コマンド・ボタンを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
|
コマンド行モード |
.bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。 |
テスト実行時のアクセス・テスターの動作について次に概要を示します。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
プロセスの概要: テスト・スクリプト実行時のアクセス・テスターの動作
アクセス・テスターが入力xmlファイルをロードします。
コマンド行モードでは、アクセス・テスターは入力テスト・スクリプトの「制御」要素内で定義された構成XMLファイルを開きます。
アクセス・テスターは、コンソールの「サーバー接続」パネル内の情報を使用してプライマリおよびセカンダリのOAMプロキシに接続します。
コマンド行モードでは、構成XMLファイル内の「接続」要素内の情報を使用します。
コマンド行モードでは、アクセス・テスターは入力スクリプトXMLファイルの「制御」要素をチェックして、コマンド行で上書きされたものがないことを確認します(コマンド行の値が優先されます)。
アクセス・テスターは、オリジナル・テスト・ケースのそれぞれについて次の処理を行います。
新しいターゲット・テスト・ケースを作成します。
OAMサーバーにオリジナル・リクエストを送信してレスポンスを収集します。
次の比較を行います。
新しいレスポンスとオリジナルのレスポンスを比較します。
レスポンス・コードを比較して、新しいターゲット・テスト・ケースのレスポンス・コードがオリジナル・テスト・ケースと異なる場合は、そのターゲット・テスト・ケースを「不一致」としてマークします。たとえば、オリジナル検証へのレスポンスが「はい」で新しい検証へのレスポンスが「いいえ」の場合は、不一致としてマークされます。
レスポンス・コードが同じで「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ファイルには、テスト実行全体のサマリーと詳細、および「不一致」とマークされたテスト・ケースが格納されます: <testname>_<testnumber_stats.xml
「ステータス・メッセージ」パネルの情報が格納される実行ログ・ファイル: <testname>_<testnumber_log.log.
マルチスレッド・モードで実行する場合、統計XMLファイルと実行ログ・ファイルのみが生成されます。
コマンド行モードでは、「アクセス・テスターのコマンド行モードについて」に示すようにアクセス・テスターは終了コードで終了します。
前提条件
テスト・スクリプトの実行方法
「入力テスト・スクリプトの作成」に示すように、アクセス・テスターを終了する前に保存テスト・スクリプトの場所を確認します。
次のいずれかの方法を使い、処理のためにテスト・スクリプトを送信します。
アクセス・テスター・コンソールでツール・バーから「スクリプトの実行」コマンド・ボタンを選択して(または「テスト」メニューの「スクリプトの実行」を選択して)プロンプトに従い、スクリプトの実行に合わせて「ステータス・メッセージ」パネルに表示されるメッセージを確認します。
コマンド行から、希望のシステム・プロパティが指定されたテスト・スクリプトを指定します。「コマンド行モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する」を参照してください。
java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true" -jar oamtest.jar
「スクリプト、ログ・ファイル、および統計の評価」に示すように、ログ・ファイルと出力ファイルを確認し、新たに作成された結果と入力スクリプトから取得した結果をアクセス・テスターが比較した後で、追加的な分析を行います。
この項では次の情報を提供します:
テスト実行終了時には、3つのドキュメントからなる「結果バンドル」が作成されます。
ターゲット・スクリプト: 新しいテスト・ケースが格納されたXMLドキュメント
|
注意: アクセス・テスターがマルチスレッド・モードで実行するように構成されている場合、ターゲット・スクリプトは作成されません。 |
実行ログ: スクリプト実行時に表示されたメッセージが格納されたテキストファイル
実行統計: テスト・メトリックと不一致要素のリストが格納されたXMLドキュメント
オリジナル・スクリプトとターゲット・スクリプト内にあるテスト・ケースの一致ペアは、テスト・ケースIDを共有しています。このIDは、オリジナル・スクリプトとターゲット・スクリプト内の個々のテスト・ケースの比較を可能にするUUID(中略)で表されます。詳細については「作成された入力テスト・スクリプトについて」を参照してください。
統計ドキュメントにはサマリー統計と詳細統計、および一致しなかったテスト・ケースのリストが格納されます。詳細統計は、さらに詳しい分析や結果履歴の記録に使用できます。サマリー統計はテスト実行の終了時に表示されるものと同じ統計で、テスト実行の結果を迅速に評価するために使用できます。統計ドキュメント内に作成される不一致テスト・ケースのリストには、表21-14に示すように、不一致をトリガーしたテスト・ケースIDと不一致の理由が含まれています。
これは、「ファイル」メニューの「構成を保存」コマンドを使用して保存した出力ファイルで、デフォルトのファイル名はconfig.xmlです。この接続構成ファイルには、アクセス・テスター・コンソールのサーバー接続パネルで指定された詳細が格納されています。
|
注意: 次のトピックに示すように、入力テスト・スクリプト・ファイルも作成されます。構成ファイル名は、アクセス・テスターをコマンド行モードで実行したときに接続ファイル内に定義された接続情報を取得できるようにするために、入力テスト・スクリプト内で使われます。 |
例21-1 接続構成ファイル
<?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>
入力テスト・スクリプトは、アクセス・テスターを使用してユーザー固有のテスト・ケースを取得することによって作成されます。「制御」要素の「configfile」属性は、OAMサーバーとの接続確立用にコマンド行モードで使用する接続構成ファイルを指定するために、作成後に更新されます。
例21-2 生成された入力テストスクリプト
<?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>
この例は、コマンド行モードでアクセス・テスターを実行して、取得した4つのテスト・ケースを実行するための入力としてscript.xmlファイルを指定することにより作成されたものです。
Dscript.scriptfile="script.xml" -jar oamtest.jar
例21-3の様々なセクションに注意してください。実行ログに示すようにこのテスト実行では不一致が見つからず、4つのリクエストのすべてが一致していることが示されています。
例21-3 テスト実行中に生成された出力ファイル
<?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>
統計ファイル(_stats.xml)は、実行ログに示されたテスト実行時にターゲット出力スクリプトとともに作成されます。script.xmlファイルは、取得した4つのテスト・ケースを実行するための入力として使われます。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
サンプル統計ドキュメントを例21-4に示します。この実行の統計は様々なセクションに示されており、これらと過去の「確認済(Known Good)」の統計と比較することができます。
例21-4 統計ドキュメントの例
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>
このサンプル実行ログは、テスト実行時に4つのテスト・ケースを実行するscript.xmlを使用して、ターゲット出力スクリプトとともに作成されたものです。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
この例を見ると、アクセス・テスターの「ステータス・メッセージ」パネルに表示される情報と同じ情報で構成されていることがわかります。テスト・ケース、テスト名、接続構成ファイル、エージェント名、接続ステータス、リクエスト評価ステータス、認証スキーム、リダイレクトURL、求められる資格証明、認証ステータスとユーザーDN、セッションID、認証ステータス、検証ステータス、サマリー統計などを確認してください。また、この実行によってターゲット・スクリプトと統計ドキュメントが作成されていることにも注意してください。
例21-5 実行ログ
[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'
