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

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 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.

  • 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 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.

  • 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.