Integrate pre-login assessment service
Create and integrate a pre-login assessment service (or questionnaire) to determine user risk before allowing login access. For example, ask COVID-19 health questions to determine user risk and allow or block users from onsite access to a work computer.
Available in Login for Mac and Login for Windows.
Prerequisites
SecureAuth® Identity Platform 19.07 or later
Create a pre-login assessment service which can be a web application that runs on a supported web browser
Complete Configure Identity Platform and Login for Endpoints and download the
config.jsonfile
Identity Platform configuration
After you create your pre-login assessment service, you can integrate it with the Identity Platform and an endpoint like Login for Mac or Login for Windows.
End users will then see the pre-login assessment service and provide answers before logging in at the endpoint (Login for Mac or Login for Windows).
Integrate the pre-login assessment service in the SecureAuth® Identity Platform Advanced Settings realm on the Adaptive Authentication tab. In the following steps, the images show a fictitious company named Acme that has set up a COVID-19 form to check employee health.
In the Identity Platform Advanced Settings, add or clone a realm.
Go to the Overview tab.
In the Details section, change the realm description and in the Look and Feel section, change the page header. Save your changes.
Go to the Adaptive Authentication tab.
In the User Risk section, do the following:
Set the user risk to Enabled by moving the slider to the ON position in green.
Add a risk provider by clicking the Add User Risk Score Provider button.
Add the risk score settings, then save your changes.
Disable other risk providers in the User Risk Score Providers table by moving the sliders to the OFF position in gray.
Edit the new risk provider by selecting the Edit (pencil) icon to the right of the name.
Specify weighting for each minimum, medium, high, and maximum event. The system uses the configured weighting to compute the end user’s risk score.
Adjust the risk score levels by moving the sliders or setting the threshold score for each range, as the red arrows show in the following image, then save your changes.
Set the user risk levels.
- High Risk
Represents the highest level of risk. Set Refuse authentication request to keep end users with high risk levels from logging in.
For example, if your questionnaire asks health-related questions and the end user's answers show that they are ill, the risk level will be high and the end user will not be allowed to log in.
- Medium Risk
For a medium risk level, set Redirect to realm or URL, so end users with medium risk levels are redirected to the realm or URL with the questionnaire you have set up. End users will need to fill out the questionnaire, and based on their answers, can or cannot log in.
- Low Risk
For a low risk level, set Resume authentication workflow so end users can bypass the questionnaire and log in.
- Score Unavailable
If a risk score is not available, for example, the risk provider is unavailable to provide a score, set the appropriate action for end users.
To read detailed descriptions of each user risk score action, see Risk check actions. To read detailed descriptions about configuring user risk scores, see SecureAuth User Risk settings.
Save your changes.
You also must add two attributes in the config.json file for the user redirect to the self-assessment service before login.
See the next section, Set redirect to self-assessment service before login.
Set redirect to self-assessment service before login
To set up the redirect to the self-assessment service (aka questionnaire) before logging in to the endpoint (Login for Mac or Login for Windows) you will need to edit the config.json file.
In the config.json file, set the options for follow_idp_redirect and adaptive_enabled to true, like the following:
"follow_idp_redirect": true, "adaptive_enabled": true
 |
Some key notes and considerations:
Login experience. If end users submit answers to the questionnaire and have their login request denied because they entered incorrect information, they can log in again after the expiration time set by the admin has passed. This log in experience can be frustrating for end users. Consider displaying a confirmation message prompting them to review their answers before submission.
Offline login. End users who are offline can bypass the questionnaire by default.
Remove "follow_idp_redirect" option. If the
follow_idp_redirectoption is removed, the default behavior is the same as if it were set tofalse.Both options set to false. If both
follow_idp_redirectandadaptive_enabledare set tofalse, end users will not see a questionnaire before log in to Mac or Windows.Log information. To view information about end users who have their login request denied because of risk score, check the Identity Platform debug logs and the Analyze API logs.
Sample login workflow with both options set to true
If both follow_idp_redirect and adaptive_enabled are set to true, then the following describes what the login workflow could look like.
This assumes that the self-service questionnaire is set up as a web page and is integrated in the Identity Platform by adding it as a risk provider. Then, when end users submit answers, the web page sends submits answers to the risk provider, and the risk provider handles business requirements, such as logging answers for compliance purposes.
End user completes authentication that validates their identity, and then sees a message that states "Additional information required. Click here to proceed."
Windows login
Mac login
After end user clicks the link, they are redirected to a pop-up form in a separate browser.
End user fills out the questionnaire, submits it, and then closes the browser, which resets the login process.
On the back end, the risk provider returns a risk score, which determines if the end user is allowed to continue.
If the risk score is above the threshold, the end user login is denied.
Windows login access denied
Mac login access denied
If the risk score is below the threshold, the end user can proceed to complete authentication as usual, such as by entering a password and fingerprint.