The Access Tester is a portable, stand-alone Java application that ships with Access Manager 11g. The Access Tester provides a functional interface between an individual IT professional or Administrator and the OAM Server.
IT professionals can use the Access Tester to verify connectivity and troubleshoot problems with the physical deployment. Application Administrators can use the Access Tester to perform a quick validation of policies. In this chapter, the term "Administrator" represents any individual who is using the Access Tester.
The Access Tester can be used from any computer having a network connection to the OAM Server. Both a graphical user interface (known as the Tester Console in this chapter) and a command-line interface are provided. Command line mode enables complete automation of test script execution in single or multi-client mode environments.
By appearing to be a real agent, the Access Tester helps with policy configuration design and troubleshooting, and sometimes with troubleshooting OAM Server responsiveness. When using the Access Tester, you must appear to be the real end user; the Access Tester does not actually communicate with a real end user.
To use the Access Tester, you must understand and administer authentication and authorization policies for an application or resource that is protected by Access Manager.
The Access Tester enables you to:
Configure a request to be sent to the OAM Server that emulates what a real agent would send to the OAM Server in a real environment.
Send your request to the OAM Server and receives a response that is the same as the response that would received by a real Agent. The Access Tester uses the OAM Access Protocol (OAP) API to send requests over the OAP channel to the OAM Proxy running as part of the OAM Server. The OAM Server processes the request and returns a response.
Process and display the server response.
Proceed in the manner a real agent would to handle the response. For example, if a Webgate determines that a resource is protected by a certificate authentication scheme, then it must obtain the end user's certificate from the http SSL connection.
In the case of a certificate authentication scheme, you must point the Access Tester to a certificate to be used as the end user's credentials.
In addition to simulating the Agent while performing functions in the previous list, the Access Tester enables you to:
Review performance characteristics of intended policy changes
Track the latency of authentication and authorization requests
Stress test the OAM Server to establish low- and high-performance watermarks relative to desired user loads, and to size back-end hardware
Stress test the policy server by running multiple concurrent tests (multi-threaded mode) with command-line mode only.
Establish performance metrics and measuring on an ongoing basis to prove desired outcomes
During basic operations, the Access Tester does not make any determination about the Server response and whether it is a right or wrong response (for instance, whether or not resource X is protected, or user Y is authorized to access resource X). When operating the Access Tester, you must be aware of the policy configuration to determine if a specific response is appropriate.
The Access Tester offers advanced functionality that enables you to group a number of individual requests into a test script that can be sent to the OAM Server for processing. The output of such a test run can be captured by the Access Tester and used to compare against a similar document containing "known good" responses. In this way, the Access Tester can be used for automated testing of policy configuration against errant changes.
Additionally, the Access Tester provides a multi-threaded capability designed to stress test the policy server. In the multi-threaded approach, you identify the number of virtual test clients to connect to the policy server and the number of iterations that each virtual client should execute a test script. This enables you to stress test the policy server.
For more information, see the following topics in this chapter:
The two primary types of actors in the OAM architecture are the policy servers (OAM Servers) and OAM policy enforcement agents (Webgates or Access Clients). In the security world, Agents represent the policy enforcement point (PEP), while OAM Servers represent the policy decision point (PDP).
The Agent plays the role of a gatekeeper to secure resources such as http-based applications and manage all interactions with the user who is trying to access that resource. This is accomplished according to access control policies maintained on the policy server (OAM Server).
The role of the OAM Server is to provide policy, identity, and session services to the Agent to properly secure application resources, authenticate and authorize users, and manage user sessions.
This core OAM product architecture revolves around the following exchanges, which drive the interaction between the Agent and OAM Server. To expose inter-operability and the key decision points, Figure 26-1 illustrates a typical OAM Agent and OAM Server interaction during a user's request for a resource.
Figure 26-1 OAM Agent (PEP) and OAM Server (PDP) Inter-operability
The following overview outlines the processing that occurs between OAM Agents and OAM Servers. During testing, the Access Tester emulates the Agent and communicates with the OAM Server while the Administrator emulates the end user.
Process overview: Interoperability between OAM Agents and OAM Servers
Establish server connectivity: The registered OAM Agent connects to the OAM Server.
The user requests accesses to a resource.
Validate resource protection: The Agent forwards the request to the OAM Server to determine if the resource is protected.
Protected: The OAM Server responds with the type of credentials required.
User credentials: Establishing the user identity enables tracking for Audit and SSO purposes, and conveyance to the application. For this, the Agent prompts the user for his credentials.
Authenticate user credentials: The Agent forwards the supplied user credentials to the OAM Server for validation.
Authentication Success: The Agent forwards the resource request to the OAM Server.
Authorize user access to a resource: The Agents must first determine if the user is allowed to access the resource by forwarding the request for access to the OAM Server for authorization policy evaluation.
The Agent grants or denies access based on the policy response.
This topic provides information about secure communications, connections, storage, input, logging, and Analysis.
Secure Communication: The Access Tester supports Open, Simple, or Cert connection modes for communication with the OAM Server:
Open mode: No security on the physical connection
Simple mode: The physical connection is encrypted using built-in certificates. With Simple mode, you are asked to enter the Global Pass Phrase that is configured for the OAM Server.
Cert mode: The physical connection is encrypted using a field-provided certificates. Access Tester Cert Mode requires:
Configuring the agent (either existing or new) for Cert mode communication.
Obtaining certificates for the agent being emulated.
Access Tester Cert Mode requires two JKS key stores, created using the importcert tool from the supplied PEM (BASE64-encoded ASCII) certificates: aaa_trust.pem, aaa_key.pem, aaa_cert.pem:
A Trust Store (file containing the JKS key store with the root CA certificate) is required.
A Key Store (file containing the JKS key store with the agent's private key and certificate) is required.
A Key Store Password is used to encrypt the Key Store with the agent certificates.
Connections: The Access Tester encrypts all password-type values that it saves to configuration files and test cases. Access Tester validates whether the pool contains valid connections. Cache flush requests are sent over an established connection (not an out-of-band connection to delete the user session (to simulate logout) over OAP. Using an already established connection can improve performance.
Persistent Storage: The Access Tester manages a number of data structures that require persistent storage between Access Tester invocations. XML-file-based storage is provided for the following types of information:
Configuration data to minimize data entry between invocations of the application (OamTestConfiguration)
Test scripts consisting of captured test cases (OamTestScriptCase)
Statistical data representing execution metric from a test run (OamTestStats)
XML Files for Input, Logging, and Analysis: The Access Tester uses a single XML schema to define all the XML documents it generates. The following XML files are produced when you run the Access Tester to process test scripts:
Configuration Script: config.xml is the output file generated using the Save Configuration command within the Access Tester. The name of this document is used within the input script to provide proper connection information to the Access Tester running in command line mode. For details, see "Saved Connection Configuration File".
Input Script: script.xml represents a script that is generated by the Access Tester after capturing one or more test cases. For details, see "Generated Input Test Script".
Target Output Script: oamtest_target.xml is generated by running the Access Tester in command line mode and specifying the input script. For details, see "Target Output File Containing Test Run Results". For example:
-Dscript.scriptfile="script.xml" -jar oamtest.jar
Statistics: oamtest_stats.xml is generated together with the output script. For details, see "Statistics Document".
Execution Log: lamtest_log.log is generated together with the output script. For details, see "Execution Log".
For more information, see "About Access Tester Modes and Administrator Interactions".
This topic describes modes, interactions, and the jar files needed to start and run the Access Tester.
Console: The Access Tester provides a single window for interactions with the user. All Access Tester operations are available in the main window, which performs as a central dashboard where users can submit specific details for the test case and view responses.
Command Line and Scripts: You can use the Access Tester command line and develop test scripts, which you can run interactively or in batches for computerized execution to maximize productivity and minimize costs and resources.
Startup and Run Time JAR Files: The Access Tester requires nap-api.jar in the same directory as the main jar oamtest.jar, which is used to start the application.
Interactions: Regardless of the mode you choose for running the Access Tester, your primary interactions with the Access Tester include:
Issuing Requests and Reviewing Results
You use the Access Tester to issue requests to the OAM Server to validate resource protection, policy configuration, user authentication, and user authorization. You can immediately analyze test case results and also retain the data for longer-term analysis, if needed.
Managing Test Scripts
You can build test scripts by capturing the data generated by test execution, which is available as stand-alone documents. You can run the test script for manual or automated analysis. The Access Tester provides for some automated analysis after each test run, while collecting full set of statistics to enable analysis after the fact.
Managing OAM Server Connectivity
You can manage application settings that include server connection information.
Figure 26-2 depicts the flow of information during operations in both Console and command-line modes. Details follow the figure. Advanced operations include building and executing test scripts.
Command-line mode enables complete automation of test script execution in single or multi-client mode environments. The Access Tester exposes a control mechanism to configure test runs without having to change "known good" input test scripts which are available in read-only mode.
Figure 26-2 User Interactions with the Access Tester
Table 26-1 describes the process flow of information during both Tester Console mode operations and command-line mode operations.
Table 26-1 User Interactions: Tester Console Mode versus Command Line Mode Operations
|Tester Console mode||Command Line Mode|
The user starts the Access Tester from the command line.
The user or a shell script starts the Access Tester in command line mode.
Cert mode for secure communication: The keystores are specified in the OamTestConfiguration.xml file containing previously saved configuration information.
The user opens a previously saved OamTestConfiguration.xml file to populate the application fields and minimize data entry, including server connection fields. Alternatively, the user can use the Tester Console and enter data manually
The Access Tester starts processing test cases based on the input script.
The user clicks the Connect button to open the connection with the OAM Server.
The Access Tester opens a connection with the OAM Server based on details in the input script.
Resource Protection: The user performs steps in a sequence to validate resource protection, authenticate user credentials, and authorize user access.
Resource Protection: The Access Tester starts processing test cases based on the input script.
When the test completes, the Access Tester generates:
Once the script completes, the Access Tester generates:
The user repeats steps as needed to complete validation
The user repeats steps as needed to complete validation.
In Cert mode, you will be prompted to identify the necessary keystores.
In Cert mode, the keystores are specified in the XML file containing previously saved configuration information.
The following overview outlines the tasks involved with using the Access Tester, and the topics where more information can be found in this chapter.
Task overview: Testing Access Manager connections and policies
Review the following topics:
Perform and capture tests using the Access Tester Console as described in "Testing Connectivity and Policies from the Access Tester Console"
Proceed to "Creating and Managing Test Cases and Scripts"