New User/Account Registration Flow

[lorthirk]

Hi all,

This is a proposal on how we could manage self registration of how we could manage self registration and new account provisioning on Kapua Console. Any feedback is greatly appreciated!

---

Kapua Account Self Regisration Flow

A new implementation on Kapua is required to allow users to self register a new user and/or account on Kapua. Such implementations is required in scenarios when manual account creation is not needed, and it can significantly speed up the provisioning of new accounts and users.

Login page

A new link to a Registration page should appear in the home page, as shown in the screenshot below:

Registration page

A new page should appear when the Register new account button is clicked on the Login page. In this new page the user requesting the new account will choice whether to create a new Kapua user using a new Username and Password credential, or to register delegating the authentication process to a configured Single Sign On Identity Provider. After authenticating the user will be asked for additional informations such as

Step One

In the first step the user will be asked whether to create a Username and Password credential or to use an external Entity Provider to create the admin user for the new account, like the example below:

Here the fields should be validated with the same rules already existing inside the console:

• Username should be at least 3 characters, and composed of only alphanumeric characters, dashes and/or underscores;
• Password should be at least 12 characters, and composed of at least an uppercase letter, a lowercase letter, a digit and a symbol;
• Password and Confirm Password fields must match;
• Email should contain a valid email address.

The Next button will dynamically enable if and only if all the validation rules pass correctly.

Alternatively the Register with SSO button can be clicked in order to use an external identity provider to provide authentication. In this case the Single Sign On feature will be configured in the Kapua backend; clicking on the button should open a popup pointing to the Identity Provider login page to initiate the OpenID Connect Authorization Code flow. Once finished, and a valid OpenID Connect ID Token is obtained, the procedure will proceed to the next step.

Step Two (optional)

Optionally, if multi tenancy self registration is enabled in the backend, the details of a new account to be created will be asked the user in the second panel of the accordion:

In this step the user will enter the following informations:

• Account name is the name of the new account, and is should be composed of at least 3 alphanumeric characters and dashes;
• Organization name is an optional field indicating the name of the organization the user belongs to; no validation rules are enforced on this field.

The Next button will once again enable if and only if all the validation rules pass correctly. Clicking the Previous button the container will show the first step once again, with the fields already populated with values previously entered.

Step Three

Once Step One and the optional Step Two are completed, in Step Three there will be a recap of all the informations submitted by the user who can review them before submitting the User creation request. No validation is needed here, since all the informations are supposed to be already validated from earlier steps.

Clicking on the Submit button will forward the User creation request to the Kapua backend, who will in turn create all the required entities according to the informations provided; the browser will be redirected to the Kapua Console login page and the User Activation Backend Flow will be triggered.

Clicking on the Previous button will instead bring back the container to Step Two, if available, or Step One otherwise. In both cases the input fields will be populated with the previously entered values.

User Activation Backend Flow

After a user submits a User Creation Request, the backend will perform the following steps:

1. A unique token will be generated by the backend identifying the User Creation Request;
2. Such token will be part of an activation URL that will be sent via email to the requester, who will be asked in the email to navigate the URL to activate the account;
3. Once the URL has been visited the backend will proceed to create all the needed entities on the database;
4. The user will be then redirected to the Kapua Console Login page so he can login with the credential he specified in the newly created account.

[ctron]

To me this seems as if Kapua would then replicate partly what e.g. Keycloak would do anyway.

I think there are two scenarios in general. Single-tenant and multi-tenant. For the multi-tenant it could be that each tenant would like to use its own SSO setup. So using a single SSO configuration may not be enough.

But even for the single-tenant, all control may be located with the SSO solution, meaning that sending out e-mails, registering a new account will all be handled by this solution. Imagine a bigger company where such a solution already is in place. Having every system replicate this process in a custom manner is not as good as re-using that central solution, which may be company wide approved and maybe even required.

So when the SSO solution comes back with a valid registration Kapua should be able to simply auto-provision a new account based on a a set of parameters (user template) which is specific for this setup and should be customizable. That way the user also has no choice of which account and user id to pick, as this is provided by the SSO solution already.

The same approach can be used for the mulit-tenant solution. With an additional step in between, the multiplexing to different SSO configurations.

So putting the SSO configuration in the account space would not only make is configurable at runtime but allow the tenant multiplexing as you can limit the each account to require a unique SSO configuration.

In addition this seems to fix the single-tenant solution as well and prevent re-implementing components which are already there.

[lorthirk]

I'm trying to figure out the full round trip for multi tenant scenarios, but I still have a major blocker in my mind: assuming we have a per-tenant SSO configuration, how could we figure out which SSO server to inquire when a user just wants to register or simply log in Kapua via SSO? Manually entering the tenant name?

[ctron]

That would be an option. You could also store this in a cookie and auto-fill that later on. Or create a special login page which is backed by the default page but the URI could contain the account name or a hint for the system on an account name (like the hashed account name).