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.
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
use the detail in Understanding events and reports to determine the Event and Report result (success, missing event, unavailable, unexpected)
follow the troubleshooting steps for that result type, as described in Using events and reports to troubleshoot
The recommended simple validation scenario includes
- Create a new user
- Authenticate to the Web application
- Complete the MFA challenge
- Gain access to the application
The scenario validates
- IBM Security Verify Adaptive Browser SDK integration
- Client browser collection and detection
- IBM Security Verify Proxy SDK invocation
- Adaptive access policy invocation and assessment
The user experience should be
- Launch the Native Web application
- Authentication challenge
- MFA challenge
- 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.
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.
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.
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.
which will return the current Session ID
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 Unavailableas a result of performing the validation scenario before the onboarding was complete.
The Policy action for the
MediumRisk level is applied.
- the middle row shows the new user assessment as
MediumRisk 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
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
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
MediumRisk 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
LowRisk level, review Unexpected evaluation decision.
Next: No event or report
Previous: Understanding events and reports