15.11 Validating Remote Registration and Resource Protection

You can validate registration of an agent regardless of the agent type.

You must be an in-band Administrator to perform tasks using the Oracle Access Management Console. Out-of-band Administrators must test authentication and access remotely.

15.11.1 Validating Agent Registration using the Oracle Access Management Console

Only an in-band Administrator can validate agent registration.

See Also:

Managing Policies to Protect Resources and Enable SSO

  1. Validate Agent Registration in the Oracle Access Management Console:

    1. Confirm Agent details under Application Security in the Oracle Access Management Console.

    2. Confirm the updated Agent configuration files are in the appropriate location, as described in "Performing Remote Registration for OAM Agents".

  2. Validate Shared Components, Host identifier: Confirm that the host identifier is defined in the Oracle Access Management Console.

  3. Validate Application Domain: Under the Policy Configuration tab, confirm there is a new Application Domain named after the registered agent. Resources in the Application Domain should be associated with the host identifier.

  4. Proceed with "Verifying Authentication and Access After Remote Registration".

15.11.2 Verifying Authentication and Access After Remote Registration

After registration, protected resource should be accessible with proper authentication without restarting the AdminServer or OAM Server.

Both in-band and out-of-band Administrators can use the following procedure to validate proper registration and policies.

The procedure here provides several methods for confirming that registration, authentication, and authorization are properly configured and operational. The procedures is nearly identical for all agent types.

  1. Enter the URL for an application protected by the registered OAM Agent to confirm that the log in page appears (proving that the authentication redirect URL was specified appropriately). For example: 
    http://exampleWebserverHost.sample.com:8100/resource1.html
  2. On the Log In page, enter a valid username and password when asked, and click Login.
  3. Check the OAM specific cookies are created in the browser session. For example:

    ObSSOCookie:

    Set-Cookie: 
ObSSOCookie=GGVEuvjmrMe%2FhbItbjT24CBmJo1eCIfDIwQ1atdGdnY4mt6kmdSekSFeAAFvFrZZZ
xDfvpkfS3ZLZFbaZU2rAn0YYUM3JUWVYkYFwB%2BBK7V4x%2FeuYHj%2B8gwOyxhNYFna3iSx1MSZBE
y51KTBfsDYOiw6R%2BCxUhOO8uZDTYHI3s0c7AQSyrEiQTuUV3nv1omaFZlk1GuZa4J7ycaGbIUyqwX
rM0cKuBJNd6sX1LiRj9HofYQsvUV7ToqeAOpDS7z9qs5LhqU5Vq60bBn12DTX6zNX6Lcc0L5tVwvh7%
2BnOAkz2%2BoDkLs%2BBTkeGcB3ppgC9;httponly; path=/; domain=.example.com;

    OAM_ID Cookie:

    Set-Cookie: 
OAM_ID=v1.0~0~E1EBBC9846E09857060A68E79AEEB608~AA79FC43C695162B6CDE3738F40E94DA
6408D58B879AC3B467EBBD4800743C899843672B3511141FFABCF58B2CDCB700C83CC734A913625
7C4ABDA6913C9EF5A4E05C5D03D3514F2FECACD02F1C1B9314D76B4A68CB7A8BE42AEB09AFB98B8
EB; path=/; HttpOnly
  4. Proceed as follows:

    • Success: If you authenticated successfully and were granted access to the resource; the configuration is working properly. Proceed with Steps 5 through 12 for further validations.

    • Failure: If you received an error during login or were denied access to the resource, check the following:

      • Login Error: Confirm that you provided a valid user id and password.

      • Unavailable Resource: Confirm that the resource is available.

      • Wrong Redirect URL: Verify the redirect URL in the Oracle Access Management Console.

  5. User Variations: Perform steps 1 through 4 again with user variations to confirm appropriate behavior (either success for authorized users or failure for unauthorized users).
  6. Request Cancellation: Perform a partial log in and click Cancel to confirm that the resource is not accessed.
  7. Modified Authentication URL: Enter a nearly identical authentication URL as you perform Steps 1 through 5 to confirm appropriate response. For example, add a character to the URL string.
  8. Updated Resource: Perform the following steps to ensure the resource is accessible. For example:

    Original Resource: /abc/test.html

    Updated Resource: /abc/xyz/test.html

    Without restarting the Oracle WebLogic Server:

    • Access the updated resource and confirm the user is asked to authenticate and the resource is accessible.

    • Access the original resource and confirm that the resource is accessible and the user is not asked for authentication.

  9. Various URL Patterns: Verify authentication for various URL patterns as you perform steps 1 through 5.
  10. New Authentication Scheme: Perform the following steps to confirm authentication operations without restarting the WebLogic Server.

    • Add a new authentication policy that uses a different Authentication Scheme.

    • Protect the resource using the new policy.

    • Without restarting the Oracle WebLogic Server, perform steps 1 through 4.

    See Also:

    Managing Policies to Protect Resources and Enable SSO

  11. CGI Resource Header Variable and Cookies: Perform the following steps to confirm authentication operations without having to restart the WebLogic Server.

    • Add a new authentication policy to protect a Common Gateway Interface (CGI) resource and set the Response for "Authentication Successful".

    • Protect the resource using the new policy.

    • Access the CGI resource.

    • Check for the header values configured for the response in a CGI data dump.

  12. Agent Disabled: Perform the following steps to validate accessibility and authentication if WebGate is disabled in ObAccessClient.xml (WebGate should pick up the enabled value from oam-config.xml).

    • Disable the Agent State.Start the Web server and OAM Server.Access an application protected by the Agent and confirm that you are asked to authenticate.