Self-registration example
17.2.3.5. 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

Possible configuration for a user self-registration flow: 

Example – User self-registration flow

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
  • 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 ist required to proceed to the next step.

2
username generation step
None.
This step is executed automatically after successful completion of the previous 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/
  • 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
  • Purpose
  • ●
    Store a password for the user.
  • Comment
  • ●
    This step enforces the configured password policy.
  • ●
    The continue REST call ist required to proceed to the next step.
5
user persisting step
None.
This step is executed automatically after a successful completion of step 4.
  • 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.

Form-based GUI for self-registration

  • For the above example a form-based GUI is expected to guide the user through the following steps:
  • 1.
    The user will provide a number of attributes including the email address.
  • 2.
    The user provides the OTP from the channel verification message.
  • 3.
    The user chooses a password.