26.5 Testing Connectivity and Policies from the Access Tester Console

You can perform quick spot checks using the Access Tester in Console mode with OAM Servers.

Spot checks or troubleshooting connections between the Agent and OAM Server can help you assess whether the Agent can communicate with the OAM Server, which is especially helpful after an upgrade or product migration. Spot checks or troubleshooting resource protection that can be exercised by Agents and OAM Servers can help you develop end-to-end tests of policy configuration during the application lifecycle.

The following overview identifies the tasks and sequence to be performed and where to locate additional information about each task.

Note:

You can capture each request and response pair to create a test case, and save the test cases to a script file that can be run later. For details, see "Creating and Managing Test Cases and Scripts".

Task overview: Performing spot checks from the Access Tester Console

Start the Access Tester, as described in "Installing and Starting the Access Tester".
Add relevant details to the Server Connection panel and click Connect, as described in "Establishing a Connection Between the Access Tester and the OAM Server".
Enter or import details into the Protected Resource URI pane and click Validate, as described in "Validating Resource Protection from the Access Tester Console".
Add relevant details to the User Identity panel and click Authenticate, as described in "Testing User Authentication from the Access Tester Console".
After successful authentication, click Authorize in the User Identity panel, as described in "Testing User Authorization from the Access Tester Console".
Check the latency of requests, as described in "Observing Request Latency".

26.5.1 Establishing a Connection Between the Access Tester and the OAM Server

Before you can send a request to the OAM Server you must establish a connection between the Access Tester and the server.

This section describes how to establish that connectivity.

26.5.1.1 Server Connection Panel in the Access Tester

You enter required information for the OAM Server and the Agent you are emulating in the Access Tester Connection panel and then click the Connect button. The Tester initiates the connection, and displays the status in the Status Messages panel. Once the connection is established, it is used for all further operations.

Caution:

Once the connection is established, it cannot be changed until you restart the Access Tester Console.

Figure 26-4 illustrates the Server Connection panel and controls. This panel contains information needed to establish a connection to the OAM Server's Proxy port.

Figure 26-4 Server Connection Panel in the Access Tester

Description of "Figure 26-4 Server Connection Panel in the Access Tester"

Table 26-7 describes the information needed to establish the connection. The source of your values is the Oracle Access Management Console, System Configuration tab.

Table 26-7 Connection Panel Information

Fields	Description
IP Address	The IP Address of the Primary and Secondary OAM Proxy listens on for this set of tests. Note: Oracle recommends that you enter values for only the Primary OAM Proxy. The Secondary OAM Proxy is needed only if you want to test failover between the primary and secondary OAM Server. However, a more practical use of the Secondary Server is reserved for later use, when the OAP API supports load balancing between Primary and Secondary OAM Server.
Port	Enter the port number of the Primary and Secondary OAM Server.
Max Conn	The maximum number of physical connection (TCP) sockets the Access Tester will use. Access Tester emulates a single threaded Agent. Note: Oracle recommends that you accept the default value, 1.
Min Conn	The minimum number of physical connection (TCP) sockets the Access Tester will use. The Access Tester emulates a single threaded Agent. Note: Oracle recommends that you accept the default value, 1.
Timeout	The number of milliseconds the Access Tester should wait for the connection to be established or to receive a response from the OAM Server. Note: Oracle recommends that you accept the default value.
Mode	The level of communication security that is designated for the Agent to be emulated. Open--No special configuration needed for this mode. Simple--Presents a field for the global pass phrase set for the OAM Server. See Also: "Retrieving the Global Passphrase for Simple Mode". Cert--Presents a Configure Certs ... button that opens a dialog asking for the following: Trust Store (Root Store Alias): A file containing the JKS key store with the root CA certificate. Key Store: A file containing the JKS key store with the agent's private key and certificate. Currently, the agent certificate is used for encrypting the connection and not the agent identification. Key Store Password: The password used to encrypt the Key Store with the agent certificates. See Also: "About Access Tester Security and Processing", and "Generating Client Keystores for OAM Tester in Cert Mode".
Agent ID	Enter the identity of the OAM Agent the Tester is simulating.
Agent Password	Enter the password for the OAM Agent the Tester is simulating, if there is one configured.
Question Mark	Click ? beside the Agent Password field for help.
Green Check Mark	The green check mark beside the Connect button indicates a "Yes" response; the connection is made. The Status Messages panel also indicates a "Yes" response for the connection.
X in red circle	The red circle beside the Connect button indicates a "No" response; no connection exists. The Status Messages panel also indicates a "No" response for the connection.

After entering information and establishing a connection, you can save details to a configuration file that can be re-used later.

26.5.1.2 Connecting the Access Tester with the OAM Server

You can submit your connection details for the OAM Server.

Note:

Cert mode requires the presence of keystores generated as described in Securing Communication

Prerequisites

Installing and Starting the Access Tester

To test connectivity between the Access Tester and the OAM Server

Start the Access Tester, as described in "Installing and Starting the Access Tester".
In the Server Connection Panel (Table 26-7), enter:
- Primary and secondary OAM Proxy details
- Timeout period
- Communication encryption mode
- Agent details
Click the Connect button.
Beside the Connect button, look for the green check mark indicating the connection is established.
In the Status Messages panel, verify a Yes response.

Not Successful: If there is a problem connecting to the OAM Server, ensure that you entered all connection information correctly (IP address and port, Agent name and password, connection mode and related certificates and passwords, as needed).

If the connection still cannot be made, start the Access Tester Console using the Trace Connection command mode and look for additional details in the connection log. Also, ask the Administrator of the OAM Server to review the policy server log.

26.5.2 Validating Resource Protection from the Access Tester Console

Before a user can access a resource, the Agent must first validate that the resource is protected.

Using the Access Tester, you can act as the Agent to have the OAM Server validate whether or not the given URI is protected and communicate the response to the Access Tester, as described here.

26.5.2.1 Protected Resource URI Panel in the Access Tester

You must enter required information for the resource you want to validate in the Access Tester Protected Resource URI panel, and then click the Validate button.

To minimize data entry, you can import long URIs that you have copied from a browser and then click the Import URI command button. The Tester parses the URI saved to the clipboard and populates the URI fields in the Access Tester.

Figure 26-5 illustrates the panel where you enter the URI details to validate that the resource is protected. When combined, the URI fields follow RFC notation. For example: http://oam_server1:7777/index.html.

Figure 26-5 Protected Resource URI Panel in the Access Tester

Description of "Figure 26-5 Protected Resource URI Panel in the Access Tester"

Table 26-8 describes the information needed to perform this validation.

Table 26-8 Protected Resource URI Panel Fields and Controls

Field or Control	Description
Scheme	Enter http or https, depending on the communication security specified for the resource. Note: The Access Tester supports only http or https resources. You cannot use the Access Tester to test policies that protect custom non-http resources.
Host	Enter a valid host name for the resource. Note: Your <host:port> combination specified in the Access Tester must match one of the Host Identifiers defined in the Oracle Access Management Console. If the host identifier is not recognized, OAM cannot validate resource protection.
Port	Enter a valid port for the URI. Note: The <host:port> combination specified in the Access Tester must match one of the Host Identifiers as defined in the OAM Server. If the host identifier is not recognized, OAM cannot validate resource protection.
Resource	Enter the Resource component of the URI (/index.htm in the example). This resource should match a resource defined for an authentication and authorization policy in the Oracle Access Management Console. Note: If protected, the resource identifier that you provide here must match the one specified in an authorization policy in the Oracle Access Management Console.
Globe with red arrow	Click this button to parse and import a URI that is saved on a clipboard.
Operation	Select the operational component of the URI from the list provided in the Access Tester. The OAM Server does not distinguish between different actions, however. Therefore, leaving this set to Get should suffice.
Get Auth Scheme	Check this box to request the OAM Server to return details about the Authentication Scheme that is used to secure the protected resource. If the URI is protected, this information is displayed in the Status Messages panel.
Validate	Click the Validate button to submit the request to the OAM Server. When the response is received, the Access Tester displays it in the Status Messages panel.
Green Check Mark	A green check mark appearing beside the Validate button indicates a "Yes" response; the resource is protected. The Status Messages panel provides the redirect URL for the resource and that credentials are expected. Note: If you checked the Get Auth Scheme box, the name and level of the Authentication Scheme that protects this resource are also provided in the Status Messages panel.
X in red circle	A red circle appearing beside the Validate button indicates that the resource is not protected. A No response will also appear in the Status Messages.

You can capture each request and response pair to create a test case, and save multiple test cases to a script file that can be run later.

See Also:

26.5.2.2 Validating Resource Protection

You can submit your resource information to the OAM Server and verify responses in the Status Messages panel.

Prerequisites

Establishing a Connection Between the Access Tester and the OAM Server

To confirm that a resource is protected

In the Access Tester Protected Resource URI panel, enter or import your own resource information (Table 26-8).
Click the Validate button to submit the request.
Review Access Tester output, including the relevant data about the resource such as how the resource is protected, level of protection, and so on.
Beside the Validate button, look for the green check mark indicating the resource is protected.
In the Status Messages panel, verify the redirect URL, authentication scheme, and that credentials are expected.
Capture the request and response to create a test case for use later, as described in "Creating and Managing Test Cases and Scripts".
Retain the URI to minimize data entry and server processing using one of the following methods.
Proceed to "Testing User Authentication from the Access Tester Console"

26.5.3 Testing User Authentication from the Access Tester Console

This topic provides the following information:

26.5.3.1 User Identity Panel in the Access Tester

Before a user can access a resource, the Agent must validate the user's identity based on the defined authentication policy on the OAM Server. Using the Access Tester, you can act as the Agent to have the OAM Server authenticate a specific userID for the protected resource. All relevant authentication responses are considered during this policy evaluation.

Figure 26-6 illustrates the Access Tester panel where you enter the information needed to test authentication.

Figure 26-6 Access Tester User Identity Panel

Description of "Figure 26-6 Access Tester User Identity Panel"

Table 26-9 describes the information you must provide.

Table 26-9 Access Tester User Identity Panel Fields and Controls

Field or Control	Description
IP Address	Enter the IP Address of the user whose credentials are being validated. All Agents communicating with the OAM Server send the IP address of the end user. Default: The IP address that is filled in belongs to the computer from which the Access Tester is run. To test a policy that requires a real user IP address, replace the default IP address with the real IP address.
User Name	Enter the userID of the individual whose credentials are being validated. Note: The Access Tester enables or disables the username and password fields if the resource is protected by an authentication scheme that requires those credentials. Similarly the Access Tester enables or disables the certificate field if the resource is protected by an authentication scheme that requires a user's X509 certificate.
Password	Enter the password of the individual whose credentials are being validated.
?	Click this button to display the password in clear text within a popup window.
User Certificate Store	The PEM format file containing the X.509 certificate of the user whose credentials should be authenticated. If the URI is protected by the X509 Authentication Scheme then the Tester will use the PEM-formatted X509 certificate as a credential instead of or in addition to the username/password. The X509 cert may also be used for authorization if security policies are so configured on the OAM Server. Note: For certificate-based authentication to work, the OAM Server must be properly configured with root CA certificates and SSL keystore certificates. See Securing Communication for details about securing communication between OAM Servers and Webgates.
...	Click this button to browse the file system for the user certificate store path.
Authenticate	Click the Authenticate button to submit the request to the OAM Server and look for a response in the Status Messages panel. Note: The type of credentials supplied (username/password or X.509 certificate) must match the requirements of the authentication scheme that protects the URI. Note: For certificate-based authentication, the OAM Server deployment must be properly configured with certificates as described in Securing Communication.
Authorize	After the user's credentials are validated, you can click the Authorize button to submit the request for the resource to the OAM Server. Check the Status Messages panel for a response. This request submits information collected in the URI and Identity panels to the OAM Server to decide if the user defined on the Identity panel can access the resource defined on the URI panel. The server returns Yes (user can access the resource) or No (user can not access the resource). The OAM Server might return additional information such as actions (responses) that the real Agent would normally handle.
Green Check Mark	A green check mark appearing beside the Authenticate button indicates authentication success; The Status Messages panel also indicates "yes" authentication was successful, and provides the user DN and session id. A green check mark appearing beside the Authorize button indicates authorization success; The Status Messages panel also indicates "yes" authorization was successful, and provides Application Domain details.
X in red circle	A red circle appearing beside the Authenticate button indicates authentication failure; The Status Messages panel also indicates "no" authentication was not successful. A red circle appearing beside the Authorize button indicates authorization failure; The Status Messages panel also indicates "no" authorization was not successful.

You can capture each request and response pair to create a test case, and save multiple test cases to a script file that can be run later.

See Also:

26.5.3.2 Testing User Credential Authentication

You can submit the end user credentials to the OAM Server and verify authentication. All relevant authentication responses are considered during this policy evaluation.

Prerequisites

Validating Resource Protection from the Access Tester Console with URI information retained in the Console.

To test user credential authentication

In the Access Tester User Identity panel, enter information for the user to be authenticated (Table 26-9).
Click the Authenticate button to submit the request.
Beside the Authenticate button, look for the green check mark indicating the user is authenticated.

Not Successful: Confirm that you entered the correct userID and password and try again. Also, check the Oracle Access Management Console for an active user session that you might need to end, as described in Maintaining Access Manager Sessions.
Capture the request and response to create a test case for use later, as described in "Creating and Managing Test Cases and Scripts".
Retain the URI and user identity information and proceed to "Testing User Authorization from the Access Tester Console".

26.5.4 Testing User Authorization from the Access Tester Console

Before a user can access a resource, the Agent must validate the user's permissions based on defined policies on the OAM Server. Using the Access Tester, you can act as the Agent to have the OAM Server validate whether or not the authenticated user identity can be authorized to access the resource. You verify the authenticated end user's authorization for the resource. All relevant authorization conditions and responses are considered during this policy evaluation.

Prerequisites

Testing User Authentication from the Access Tester Console with all information retained in the Console.

Note:

Once the protected resource URI is confirmed and the user's identity is authenticated from the Access Tester, no further information is needed. You simply click the Authorize button to submit the request. However, if the resource is changed to another you must start the sequence anew and validate, then authenticate, and then authorize.

To test user authorization

In the Access Tester User Identity panel, confirm the user is authenticated (Table 26-9).
In the Access Tester User Identity panel, click the Authorization button.
Beside the Authorization button, look for the green check mark indicating the user is authorized.

Not Successful: Confirm the authorization policy using the Oracle Access Management Console.
In the Status Messages panel (or execution log file), verify details about the test run.
Capture the request and response to create a test case for use later, as described in "Creating and Managing Test Cases and Scripts".
Proceed to:

26.5.5 Observing Request Latency

To understand OAM Server performance you must know how well the OAM Server handles requests passed by the Agent. While there are many ways to expose a server's metrics, it is sometimes useful to expose server performance from the standpoint of the Agent.

Using the Access Tester, you can do just that as described here.

Prerequisites

"Installing and Starting the Access Tester"

Task overview: Observing request latency includes

"Validating Resource Protection"
"Testing User Authentication from the Access Tester Console"
"Testing User Authorization from the Access Tester Console"

Check latency information in the execution log file as shown here, as well as in other files generated during a test run. For example:

...
[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
...

Proceed to:
- Creating and Managing Test Cases and Scripts
- Evaluating Scripts, Log File, and Statistics