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
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.
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
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.
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.
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
See Also:
To test connectivity between the Access Tester and the OAM Server
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.
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
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.
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
This topic provides the following information:
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
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.
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.
See Also:
To test user credential authentication
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.
See Also:
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
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