Configuration of self-registration Configuration - user self-registration flows

To configure user self-registration flows, go to:

Loginapp >> Self-Registration Flows

The example used in this article is based on the flow described in Example – User self-registration flow.

It uses the following steps

  • 1.
    User Data Registration Step: for the email address and context data registration
  • 2.
    Username Generation Step
  • 3.
    Email Verification Step
  • 4.
    User Data Registration Step: for password registration
  • 5.
    User Persisting Step Self-registration flow steps Configuration of a user data registration step

A user data registration step contains one or more user data items.

A user data registration step may also configure a validator to validate some rules that are applicable to more than one user data item. 


When configuring a context data item for use with the self-registration step, it is possible to define the context data item as required and to optionally configure a list of validators 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.
  • White-List allowed characters in Strings using a regular expression. General remarks on channel verification configurations

Channel Verification can be used to achieve different goals, which have different configurations requirements:

Goal of Channel Verification
Configuration Requirements
Ensure that the user entered the email address or phone number correctly (no typo).
The verification OTP can be short to increase usability since brute-forcing is pointless. Stealth Mode is not needed.
Ensure that the user is in control of the email address or phone number.
The verification OTP should be long enough to prevent brute-forcing (by repeatedly restarting the self-registration). Stealth Mode is not needed.
Prevent users from finding out if someone else's email address or phone number is already registered.
This is the only use-case that requires Stealth Mode (see below). In addition, a long OTP should be used to prevent probabilistic enumeration attacks. Configuration of an email verification step

When adding an email verification step this requires the configuration of a mail service, an OTP generator, and a message template:


Note that the "Max Failed Attempts" property only limits the attempts during a registration attempt. It cannot prevent repeated attempts with the same email address. Configuration of a phone number verification step (mTAN/SMS)

When adding a phone number verification step, the configuration of an SMS gateway, an OTP generator, and a message template is required.


Note that the "Max Failed Attempts" property only limits the attempts during a registration attempt. It cannot prevent repeated attempts with the same phone number. Configuration of a username generation step

The username generator supports two types of generators. A UUID generator and a customizable identity generator.

83101742.png Configuration of the user persisting step

Apart from the persistency strategy, this step requires no further configuration.

83101747.png Configuration of the email address as an alias

The term alias is used here to indicate a context data item that is configured in such a manner that it can be used as a login name 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, Stealth Mode can effectively protect it against enumeration attacks. (). Configuration of multiple self-registration flows

It is possible to configure multiple Flows that the users may select. The corresponding REST calls are explained in Loginapp REST API Reference.


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. Configuration of identity propagation

Using the "Identity Propagation" property it is possible to propagate the user's identity after the self-registration flow has successfully completed.

In conjunction with "Airlock Gateway (WAF) Mapping Roles (Credentials)" it can make protected applications or services available to users right after self-registration. Example: Using identity propagation to access the Loginapp's protected REST API

It is possible to give users access to the Loginapp's protected REST API directly after self-registration as shown in the following example:

  • 1.
    In property "Identity Propagation" use plugin "REST Identity Propagation Plugin"
  • 2.
    Within it, use the "Cookie Ticket Identity Propagator"
  • 3.
    Go to the Loginapp "REST API Configuration API" configuration.
  • 4.
    Set the "SSO Credential Authenticator" Plugin in the "Authenticator" property.
  • 5.
    Set the "Cookie Ticket Credential Policy" in the "Request Credential Policy" property and configure it accordingly. Uniqueness and aliases

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

The configuration of aliases can be found here 10.6. Username transformation: Login with multiple IDs. Limitations with LDAP and MS-AD

Using self-registration with different data persisters may limit the available functionality as follows:

Data Persister
No known limitations.
ldap directory
The only data type supported is a string. Data type boolean or date cannot be used.
Microsoft Active Directory
Microsoft AD may work with the "LDAP Connector" but this is not a supported use case.