Successful evaluation

Having successfully deployed your Web application and incorporated the IBM Security Verify Adaptive Browser SDK and IBM Security Verify Proxy SDK an end to end validation can be completed.

Validation scenario

We can use a simple validation scenario to ensure the configuration of the Native Web application and Adaptive access is correct.
If the scenario is not successful you should

1. use the detail in Understanding events and reports to determine the Event and Report result (success, missing event, unavailable, unexpected)

2. follow the troubleshooting steps for that result type, as described in Using events and reports to troubleshoot

3. The recommended simple validation scenario includes

   1. Create a new user
   2. Authenticate to the Web application
   3. Complete the MFA challenge
   4. Gain access to the application

4. The scenario validates

   1. IBM Security Verify Adaptive Browser SDK integration
   2. Client browser collection and detection
   3. IBM Security Verify Proxy SDK invocation
   4. Adaptive access policy invocation and assessment

5. The user experience should be

   1. Launch the Native Web application
   2. Authentication challenge
   3. MFA challenge
   4. Allowed access

Refer to Scenario troubleshooting if the validation scenario did not execute correctly.

Web application login page

Using the browser's Developer Tools, check that the Browser SDK starts Adaptive access collection and detection.
These requests should be visible in Network tab and include a request to the frontend host (<snippet host>) and Snippet ID (<snippet ID>) configured in the Browser SDK that were generated during application onboarding in the IBM® Security Verify administration console or IBM® Security Verify Developer portal application.
For example https://d1anfu45urknyg.cloudfront.net/511843/aloads.js?dt=login&r=0.3289762412868322.
You should see additional JavaScript loaders requested, which may include

• bits.js
• main.js
• tags.js

These loaders should return a 200 response code with a non-empty response body.

Aditionally, you should see multiple other requests to the same frontend host with different URI paths as the collection continues.

Session ID

During the invocation of getSessionId() from the Browser SDK, the Console of the browser Developer Tools will display the Session ID that can be used to perform Session ID correlation with the Events service API or Adaptive access report.
For example

CDN snippet loaded
[:getTCSID(csid)] csid: pp24c528943651cbe63c91dd0590b24323a80a0b401600954689
[:getFlow()]
Gathering complete, session ID received: pp24c528943651cbe63c91dd0590b24323a80a0b401600954689

If the trace output has been cleared or Developer Tools was not open during the collection and the Session ID is not visible, you can invoke the Browser SDK to output the Session ID without triggering recollection.

await getSessionId()

which will return the current Session ID

pp24c528943651cbe63c91dd0590b24323a80a0b401600954689

Adaptive access policy

The Adaptive access policy for Native applications is evaluated.
When using the recommended action of MFA per session for Medium Risk level in the Post authentication rules, new users will be challenged for MFA during the session establishment.
After completing the MFA, the user session will be reduced to Low Risk level and the user allowed access to the application - unless the same user attempts to log in from a new device.

Adaptive access report

When using the recommended Adaptive access policy the new user will be evaluated as Medium Risk level^* and challenged for MFA (per session).
After completing the MFA challenge the Adaptive access policy is re-evaluated and the user should now be assessed as Low Risk level and allowed access.

^*If the collection and detection indicates specific Risk indications, the user may be assessed at a higher Risk level.
Risk level examples are described in Trust score risk levels.

In this Adaptive access report example

• the bottom row indicates Risk Service Unavailable as a result of performing the validation scenario before the onboarding was complete.
  The Policy action for the Medium Risk level is applied.
• the middle row shows the new user assessment as Medium Risk level, as this is the first time this user has been assessed on this device.
• the top row shows the policy re-evaluation after successful MFA.
  Now the user is verified using this browser for this application and assessed as Low Risk level.

Key details for the evaluation are displayed when selecting an event row.
The Session ID should correspond to the one generated by the Web SDK in Web application login page.

During subsequent authentications (logins) or token refresh, the user should continue to be assessed as Low Risk level unless an Adaptive details indicator is triggered which will alter the user's Risk level, for example, one or more of:

• Behavioral anomaly
• New device
• Risky device
• Risky connection
• New location

Scenario troubleshooting

If the validation scenario did not execute correctly, troubleshooting can commence by following the data gathering described in Understanding events and reports.

• Perform Session ID correlation between the Web application login page and the Events service API or Adaptive access report.
• If the Adaptive access collection and detection did not complete successfully in Web application login page, no Session ID will be generated.
  After multiple unsuccessful collection attempts the Adaptive access policy will return the policy action of the Medium Risk level which results in Risk Service Unavailable being generated.
• If the Web application did not attempt to have the user session recollected No event or report will be created in the Adaptive access report.
• If the user was not prompted for MFA, or continues to be assessed higher than Low Risk level, review Unexpected evaluation decision.

Next: No event or report

Previous: Understanding events and reports