General settings

This article explains the general settings for Adaptive Access in Strivacity, allowing you to customize and enhance the security of your authentication processes. By configuring these settings, you can fine-tune how Adaptive Access responds to different login scenarios, helping to enhance the security and flexibility of your access controls.

Configuration

To configure the general settings for your Adaptive Access policy, follow these steps:

Go to Adaptive Access under Policies in the left-hand menu.
Look for the left-hand panel on the page that opens to find the general settings.

General settings

Setting	Description
Adaptive access policy name	The name of the Adaptive access policy (mandatory). The policy will be referenced by this name in Strivacity.
Adaptive access policy login workflow	You can select from built-in login workflows to set up a customer journey for your application.
Allow lifecycle event hooks to suppress passwords	Let administrators configure hooks that avoid storing passwords during lifecycle events, bolstering security without compromising customer management functionality.
Attribute-based account recovery	By default, customers can only receive reminders to their confirmed email address or phone number. This setting allows you to remove this dependency and allow the use of non-confirmed attributes for account recovery methods too.
Enable MFA for external logins	You can enable this option if you would like to use Strivacity's MFA enrollment and authentication for external logins instead of the external provider's MFA. ❗Device recognition is not available for external identities. This option is disabled by default.

Login workflows

Strivacity lets you add a unique customer journey with its own login workflow to each of your Applications.

Login workflow	Customer journey
Username → MFA → Password	The default workflow for Strivacity is included within the default Adaptive access policy. Requires an identifier from the customer, then an MFA method, and finally, their password. This workflow prevents account lockout that otherwise occurs by password brute-force attacks.
Username → Password → MFA	Requires an identifier from the customer, then their password, and finally, the customer is stepped up to MFA.
Passwordless (Username → MFA)	Requires an identifier from the customer, then the customer is stepped up to MFA. No password is required. While this workflow arguably only applies a single factor, it removes the attack vector of the secret (the password) being stolen (and used) by an attacker entirely.
Username → Password (single factor only)	The username and password workflow is just that!

📘
Passwordless workflow: if your customer hasn't enrolled yet in an MFA method or step-down rules apply to the geographical region or IP address they are accessing your applications from, they will be asked to provide their password for authentication.