Add optional ability to associate TenantId about brockallen.membershipreboot

[brockallen]

So just brainstorming here... we either add a new column to the user table with this or do it as a extra claim.

If we do it as a new column, then I'd also still like a option somewhere that forces unique usernames across all tenants. Login then gets tricky -- do we ask them for the tenant as well, or do we just check all matching usernames until one password works (ick). But users won't always know the tenant name either and I don't think we want to show the tenant names in a list on the login screen.

As a claim then there's nothing in the core infrastructure that helps with this at all (that could be good or bad).

Any other thoughts?

[brockallen]

I added the beginnings of multi-tenant support. I have a new security setting which indicates if you want multi-tenant or not (it defaults to false). All the account related APIs now have overloads that accept the tenant, but all the old APIs still exists and they use a default tenant name.

I guess the real trick is to now think about how the UI wants to surface the mult-tenant aspect of the identity system. I imagine in many apps this wants to be hidden from the user and then the tenant will be inferred or supplied somehow at runtime.

But the core "engine" itself now supports it. The rest is up to the consuming application.