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
![Example – User self-registration flow](../media/05_Media/XML-Diagrameditor/IAM/Example__e2_80_93_User_self-registration_flow.theme/1.4/en-us.Example__e2_80_93_User_self-registration_flow_html.png)
The flow demonstrates 5 steps with the following characteristics:
Step | Type | REST Calls |
---|---|---|
1 | user data registration step | /public/user-self-registration/registration/data/ |
In the Demo configuration a few characteristics are demonstrated: 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. |
For more information on stealth. | ||
3 | email verification step | /public/user-self-registration/verification/email/otp/check/ |
For more details on how this protects against enumeration . | ||
4 | user data registration step | /public/user-self-registration/registration/password/ |
| ||
5 | user persisting step | None. This step is executed automatically after the successful completion of step 4. |
|
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.