[FR] Multi-Tenancy doesn't check for existence of a tenant

[Dinuz]

Is your feature request related to a problem? Please describe.
The issue is related with the creation of a tenant using the sdk server side. The sdk is missing a way to check if the tenant (the displayName to be precise) already exist in the project. The sdk will create a tenant with a different id but with the same name if the create operation is performed multiple times with the same parameter. I do understand that the sdk distinguish the tenants using the id, but it is not very friendly.

Describe the solution you'd like
It would be much better if the sdk would mock the behavior and strategy used in the creation of a user (it checks for example if the email is already in use, and if it is it throws an exception). The sdk checks if the displayname is already taken and if so throw an exception. This feature could easily been optional, and the developer decide if enforce it.

Describe alternatives you've considered
For now I am just checking if the displayname exist in a json object that works as map between tenant's name and tenant's id. It easier to deal with a name (decided upfront by the developer) than relies on an ID automatically generated by the cloud.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hiranya911]

I don't think display name is expected to be unique. And it is also pretty easy to update, if multiple tenants having the same display name is causing any confusion.

@bojeil-google what do you think?

[wuyanna]

It's true that display name is not expected to be unique. We do have a plan to allow customers to specify tenant ID when creating tenants in the future, which could solve your problem.

[Dinuz]

@hiranya911 it is not creating so much confusion as it is, what create a bit of a mess is the following situation, using multi-tenants:

let's say I do have an app that implements a multi-tenancy strategy.
Now let's say that I do decide to use a subdomain strategy to allow the tenants to access the app in a personalized way. In this case, it is just natural to use as subdomain the name of the tenant and not its id:

It will be absolutely weird using a tenant id ( eg google.mydomain.com and not google-Tr6W.mydomain.com). Now said so, the subdomain string can be used to trigger the specific tenant (in the backend), after clearly perform all the validation. But in this case if I use the tenant name (natural) I do need to map it to the ID of the specific tenant (otherwise I cannot use tenantManager and tenantAuth).

This will require or a call to get the whole tenant list and sort it out or loading a tenant map from storage.

Hope this clarify where I came from. On top of this, I don't get why the tenant name should not be unique, in which situation in the same app there are multiple tenant id with same name? I don't see a practical case.

From this point of view, specifying my own ID will not really solve the issue (actually it can make it worst, because how the unicity is guarantee?)
I see the tenant name as the email of a registered user, it should be unique. Maybe, you can add a parameter that identify uniquely the tenant (a corporate name for example), and leave the display name free (exactly as it is done with the user).

[hiranya911]

I'll let @wuyanna or @bojeil-google from the Auth team provide a more detailed answer. But from what I can understand, displayName is just that -- a name for display purposes. Uniqueness is not guaranteed or even required. Tenant ID is the only unique key. Somebody may wish to implement their own tenant management dashboard, and group certain tenants together on the screen by assigning them the same or similar display names. It's a somewhat convoluted use case, but a case can be made for that.

Once it is possible to set user-defined tenant IDs, it should be pretty straightforward to implement your particular scenario. If you want to treat foo.mydomain.com and bar.mydomain.com as separate tenants, just map "foo" and "bar" to tenant IDs. You can also use the same as display names if you like. Something like:

const subdomain = 'foo';
await admin.auth().tenantManager.createTenant({
  id: `tenant-${subdomain}`,
  displayName: subdomain,
  // ...
})

const client = admin.auth().tenantManager.forTenant(`tenant-${subdomain}`);

[wuyanna]

@hiranya911 is correct. Unlike email, which is used to uniquely identify a user, displayName is just for displaying purpose, which is just like the displayName in UserRecord. While not so often, it is possible that 2 companies happen to have the same name just like users usually do.

By allowing customer-specified tenant ID, the tenant ID becomes essentially the same thing as what you referred to as 'tenant name'. @hiranya911 provided a good code example above.

[Dinuz]

@wuyanna and @hiranya911 thank you very much for the answers. I then correctly understood. I am sorry I couldn’t really visualize a scenario where you would use different tenantIDs with the same display name. I am still not really convinced of the utility of it, and looks a bit of a stretch, but you guys said so, and I am taking it for granted.

Again you just confirmed what I thought: the tenantId will become the “name” with the new feature. However I do think that keeping the ID as random generated, and adding an extra parameter (similar concept of email) would be more beneficial in the long run, considering that the auth would be used server side anyway. My 2 cents.

[wuyanna]

Thanks for the valuable input, @Dinuz ! We will for sure take that into consideration in our planning.