User self-registration flows configuration

To configure user self-registration flows, go to:
Loginapp >> Self-Registration Flows

The example used in this article is based on this flow configuration:

By default, self-registered accounts are locked when they are initially created. In the Initial Lock Reason parameter, the lock reason of the initial lock can be configured.

The Password Repository parameter is used to define how passwords of the newly created user are stored.

A User Data Registration Step contains one or more user data items.

A user data registration step may also configure a validator to validate rules that are applicable to more than one user data item and force the user to solve a CAPTCHA before continuing the flow.

Context data items may be marked as required and validators can be added to ensure that only properly formatted data is accepted by the system. 

As an alternative to the Regex String Validator, an Email Address Validator is also provided as a way to conveniently validate email addresses.

• It is recommended to carefully validate the length and content of data sent by (potentially adversarial) users:
• Use the existing validators, e.g. for email addresses and phone numbers.
• Limit the allowed length of the received data by using a regular expression.
• Whitelist allowed characters in strings using a regular expression.

The Username Generation Step is used to generate a user ID. It is used if the information entered by the user cannot be used as a unique username. If the user, for example, registers the email address and you do not want to use it as unique identifier of the account, a Username Generation Step is required. Note that, in this example, you may still use the email address to log in afterwards.

The username generator supports two types of generators. One producing UUIDs and one generating random IDs based on a configurable pattern.

There are several identity verification steps based on sending emails or SMS messages. Identity verification steps can be used to achieve different goals:

The Email Verification Step sends an email with an OTP to the email address registered in a previous step of the flow. It requires an email service, an OTP generator, and a message template:

Note that the Max Failed Attempts property only limits the number of attempts to enter the correct OTP. It cannot prevent repeated registration attempts with the same email address.

The Phone Number Verification Step sends an SMS to the mobile phone number registered in a previous step. It requires an SMS Gateway, an OTP generator, and a message template.

Note that the Max Failed Attempts property only limits the attempts to enter the correct OTP. It cannot prevent repeated registration attempts with the same phone number.

Another User Data Registration Step is configured to allow the user to choose a password.

Note that the Loginapp UI automatically provides a user interface in which the user has to enter the password twice.

The User Role Assignment Step can be used to assign static roles to the user.

A role assigned during self-registration is persisted with the user and may be used for authorization decisions in other flows.

The Airlock 2FA Activation Step allows the user to enroll the Airlock 2FA App directly during self-registration.

To configure the Airlock 2FA Activation Step, the Airlock 2FA Settings and an Enrollment Timeout must be set.

Note that enrolling the Airlock 2FA App during the self-registration and using it as 2nd factor does not necessarily lead to strong authentication.

While it greatly improves the confidence that a returning user is the same as the one that self-registered, it does not prove that the user really is who he or she claims to be.

In order to ensure the authenticity of the self-registered user (making sure the user is who he or she claims to be) and additional verification is strictly required (e.g. ID proofing, activation letter, or similar).

It is not possible to combine an Airlock 2FA Activation Step with an Airlock 2FA Activation Letter Order Step in the same self-registration flow.

Use the Active Authentication Method step with AIRLOCK_2FA for the Auth Method parameter to directly configure the user account with Airlock 2FA as the authentication method.

By default, all users are locked when they start a self-registration flow. A User Unlock Step must be configured to change the newly created account's state to unlocked.

The User Unlock Step must be configured before the last User Persisting Step to ensure that the user account is stored as unlocked.

The User Persisting Step stores the data determined in the previous steps in the database and with it creates the IAM user account. It is usually, but not necessarily the last step. Typically confirmation (using the Acknowledge Message Step) is shown after storing the account.

Note that some steps may require a stored user account and must be placed after the User Persisting Steps.

Example: Send Email Link Step

An alias is a context data item that is configured to be used to log in with (instead of the username).

The use of the user's email address as an alias is a recommended best practice for the configuration of user self-registration. Done correctly several goals can be achieved without any impact on the user experience:

1. Using the email address as an alias makes it very simple for the user to remember the login name.
2. Segregating email and username allows the user to modify the email address during the lifetime of the account.
3. If the email alias is the target of the first channel verification, the stealth mode feature can effectively protect it against enumeration attacks.

Configuring a context data item as an alias already ensures that the context data item is unique in the database. Additionally configuring a uniqueness constraint on the same User Profile Item will therefore lead to conflicts and should be avoided.

More information on the configuration of aliases can be found in Username transformation: Login with multiple IDs.

It is possible to configure multiple self-registration flows. How to select one of the flows is explained in Loginapp REST API Reference (and in Configuration - User Self-Registration UI for the Loginapp UI).

Note that allowing several self-registration flows may have security impacts:

• As the REST client may choose the flow to register a user account, an attacker may choose the weakest flow. E.g., if one of the flows allows registration without channel verification, the adversary may choose that flow in order to register users easily.
• If Stealth Mode is used, a flow protects against enumeration of a specific channel verification target. Make sure that other flows cannot be used to perform enumeration of that channel verification target. E.g., if a channel verification target 'email' is used in one flow and 'email' can be set without channel verification in a different flow, enumeration is possible.

There are limitations when using the self-registration features with LDAPs and MSAD.

• Example – User self-registration flow presents an example that shows the interaction between flow steps and REST API calls during a simple self-registration flow.