Example – User self-registration flow

This example presents a self-registration using email for channel verification. The same self-registration process could be implemented using an mTAN/SMS phone number for channel verification.

Simplified flowchart

The flow demonstrates 5 steps with the following characteristics:

Step	Type	REST Calls
1	user data registration step	/public/user-self-registration/registration/data/ /public/user-self-registration/registration/continue
1	user data registration step	Purpose Collect mandatory attributes of the user (e.g. given name, surname). Collect optional attributes of the user (e.g. town, birthdate). Set email as an alias for the username. Comment In the Demo configuration a few characteristics are demonstrated: Email is configured as an alias (uniqueness required) and mandatory field of type Email (formatting requirements). Given Name and Surname are configured as mandatory string fields. Birthdate and Town are configured as optional strings. The continue REST call is required to proceed to the next step.
2	username generation step	None. This step is executed automatically after the successful completion of the previous step.
2	username generation step	Purpose This step generates a login name based on the configuration. This step is non-interactive. Comment It is good practice to create a long and complex login name to ensure that login name enumeration is extremely difficult. For more information on stealth.
3	email verification step	/public/user-self-registration/verification/email/otp/check/
3	email verification step	Purpose This step is used to verify that the user-supplied OTP is identical to the generated OTP. Comment The email verification step generates an OTP message and sends it to the email address provided. The success of this step guarantees that the email address is valid and that the self-registering user was in control of the email address during the registration process. All subsequent steps can only be executed if the user was able to prove possession by answering the OTP challenge sent to the email address. For more details on how this protects against enumeration .
4	user data registration step	/public/user-self-registration/registration/password/ /public/user-self-registration/registration/continue
4	user data registration step	Purpose Store a password for the user. Comment This step enforces the configured password policy. The continue REST call is required to proceed to the next step.
5	user persisting step	None. This step is executed automatically after the successful completion of step 4.
5	user persisting step	Purpose Persist the newly created user in the persistency layer. When this step completes, the flow has successfully completed as well. This step is non-interactive. Comment None.

Known limitations

Care should be taken when configuring self-registration flows for accounts with alias usernames without verification steps. Such setups are subject to race conditions and it may be possible for an attacker to generate multiple user accounts with the same alias. While such accounts are unusable and will not affect the normal operation of Airlock IAM, it is not desirable for an attacker to be able to create them.

To avoid this problem, it is possible to configure a unique index on the database to force all attributes in the username alias to be unique.