Use case: I'm using a multi-tenancy for my asp.net core app however, different tenants/companies are stored on the same schema and the same database. Since each tenant/company is different from each other and have no access to each other, the app should allow registering users that are unique within a company. In otherwords, it should allow saving users to the database with the same username but have different tenant/company id.
Issue: ASP.NET Core 2 is creating a UniqueUsername index that does not allow me to add a user with the same username. Is there another way to override this index in Code-First approach? Something like transforming this UniqueUsername index to UniqueUsername+company id, wherein the user is unique per username per company.
@ajcvickers This looks like an EF question really, so here you go :)
@blowdart I don't think this is an issue with EF core or a question but an issue with Identity
Issue: A unique constraint is hard-coded to the IdentityUserContext. This means that it does not allow me to implement a multi-tenant users. The current architecture is only good for multi-tenant apps where each tenant database is being hosted to different servers. But in the case of multi-tenancy where companies/tenants share a single database, it's not possible to do with the current version of Asp.net core Identity library.

Expectation:
I should be able to make the user (IdentityUser) unique per username (NormalizeName) per CompanyId (another field). This should be also the same with identity Roles.
True, Identity was never designed for, nor meant for multi-tenancy. We've had people do it, via various unsupported means, and you can override that OnModelBuilding to try a composite key, but, again, you're heading down the unsupported route. I tagged Arthur in case it had details on how you'd change the model to do what you want.
Thanks @blowdart I actually tried to override the OnModelBuilding but it's giving me errors like the image below:

Anyway, I already filed a similar issue in EF core repo and I hope
@ajcvickers can help me with this. Thanks! :)
https://github.com/aspnet/EntityFrameworkCore/issues/10511
@whizkidwwe1217 It might be possible to change that index and retain an EF model that still works correctly, but this will be more than a simple change in OnModelCreating and would require an intimate knowledge of how Identity is currently using the model. I don't have enough knowledge to do that, and based on my understanding from others there is little chance of getting it to work correctly since Identity was not designed to support this.
Something you can try is to use a convention like {tenantId}-{userName} as the user name for identity
I actually managed to make it work by creating a custom user validator and I didn't use IdentityDbContext. Instead, I derived a new db context from DbContext class and copied all dbsets and configurations from identity context. Kind of a hack actually but it works.
This should be groups or tenants so that the users are nested under different companies
Identity is missing this.. blodart is simply lazy to provide this feature to the community..
on github alone there are over 300 questions around this for a quick search, under identity, groups, roles etc..
so many people are requesting groups and tenants
https://github.com/aspnet/Identity/issues?utf8=%E2%9C%93&q=is%3Aissue+group , https://github.com/aspnet/Identity/issues/1532 ,
https://github.com/aspnet/Identity/issues/545 ,
https://github.com/aspnet/Identity/issues/184 ,
https://github.com/aspnet/Identity/issues/586 ,
https://github.com/aspnet/Identity/issues/184 ,
https://github.com/aspnet/Identity/issues/83 ,
https://github.com/aspnet/Identity/issues/62 ,
https://github.com/aspnet/Identity/issues/1187 ,
https://github.com/aspnet/Identity/issues/1518
The baking-in of a Unique constraint on a field as mundane as UserName seems at best an oversight: multi-tenancy capabilities OOTB should be a given (or at least don't place a constraint that makes multi-tenancy almost impossible). Further, while not that difficult to implement in to EF in general, soft delete capabilities OOTB is something I've long felt should be there - and dropping soft delete functionality in to any EFCore system using Identity only exacerbates this unique constraint issue.
In my experience, UserName is very seldom used, with preference being for Email signins instead - with this in mind it was pretty simple to implement @HaoK 's solution above. In my case I set all UserName values equal to Email + random, 5-character numeric string (a single line of code during user creation) - the problem goes away.
@challamzinniagroup it's just so bad when you're putting in some random strings when it doesn't have to be. I'll already solved this issue by extending and overriding the IdentityManager class. That way I was able to customize it and was able decide how it will be persisted to the database.