User registration strategy

[shwabnitz]

A user registration without a tenant makes no sense, see also @mshima last comment at issue #10.

If the user would be able to choose the tenant, he would be able to see all tenants to choose from one. This is a security problem. An allowed list of domain names for user email addresses associated with tenants can be an unambiguous indication. But even then a tenant administrator must be able to deny a users registration (or must confirm it). Background: this could be a paid service and the tenant (the customer of the service) only bought a 5 user license for example. So the registration would rather be a "registration request" to the tenant administrator. But definitely this is an option.

This brings me also to another approach / use cases for business applications managing confidential data in which only authorized people are allowed to access tenant's data:

• Self registering of a user ALWAYS creates a new tenant (with some required fields). To this tenant the user is associated to as tenant's administrator.
• Further tenant users and their roles must be created by the tenant's administrator within the application

[mshima]

Can be done by:

• Route the user registration to a new unsecured service that creates a Tenant then creates a user that belongs to this tenant.

• Expose Tenant's data to the registration form.

[shwabnitz]

This is a good approach. Looking from a high level to user stories / use cases this would be a useful feature for the blueprint itself. My question here is: do you implement that as a feature or would that be a specific feature of my application which I need to implement?