MultiTenancy about identityserver3 HOT 16 CLOSED

No plans for that right now. It complicates the code base quite a bit and is a niche scenario.

..or do you have an idea how we could "prepare" for that feature without having a default implementation for it.

from identityserver3.

I haven't thought yet how we could prepare the current implementation but I
already implemented a modification on the project that allows multiple
tenants and i tested it for now only on "implicit client". Assuming that i
took the correct approach, we could spot the changes and "prepare" that
sections to support multitenants.

Basically the flow is:

1. Pass the tenant to the IdentityServer: I just add a query string
   tenant indicating the tenant to which we want to use.
2. Storing the tenant into the session of IdentityServer: I haven't done
   anything there because is already stored on the return URL of the JWT
   message
3. Searching into the list of users that belongs to that tenant only:
   Whenever i need the tenant property (look up to the list of users filtered
   by tenant) i retrieve the tenant from the querystring of the return url
   that is stored on the JWT message (eg: ?client_id=implicit client&
   tenant=myTenant&...)
4. We don't need anything else, if the user logging correctly we return
   the token. (probably we would need to add a tenant property on the token to
   validate which tenant has being logged into)

Additionally to this, we have to make sure that if the user is logged in
already into the identity server, the user belongs to the tenant we are
requesting:

1. Once the validation is successful, we need to add a new clam
   containing the tenant used into the identity principal (so on the future we
   can know which tenant is that user from).
2. Whenever we validate if the client is logged in or no, we have to
   validate as well that the claim "tenant" that the user has is the same as
   the current requested tenant.

This is the approach that i used to adapt the project to use Tenants but my
experience/knowledge about identityServers is very limited, could you check
if this flow is correct?

On 12 April 2014 17:05, Dominick Baier [email protected] wrote:

No plans for that right now. It complicates the code base quite a bit and
is a niche scenario.

..or do you have an idea how we could "prepare" for that feature without
having a default implementation for it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-40284341
.

Albert.

from identityserver3.

@ascoro Is that modification up on github? I'd also like to be able to manage 2+ sets of 'identities' on the same idP (I'd like them to automatically have different claims/scopes/profile associated with them) that my RPs can use to distinguish them, depending on which 'tenant/realm' they identified against.

from identityserver3.

@ciaranj that code is not on github, i was just playing around to get familiar with the code base. I would like first to confirm that the approach taken is correct before i work on a tidy implementation of it.

As far as I understood, the claims are on a user basis not in a tenant level, the only thing that tenants provide is the ability to have different sets of identities.

from identityserver3.

So - IOW the only thing you really need is the ability to pass the tenant into the UserService.AuthenticateLocal method? Based on the subject id that comes back, you can retrieve all information you want at token issue time...

Or am I missing something?

from identityserver3.

Can a tenant (name or even better id) be a reserved claim that IdSvr would automatically use to filter via UserService? That way if you "enable" multitenancy, a particular claim is required when user identity is created. IdSvr would then use this when "using" UserService and client does not have to pass in extra parameters.

The other approach is to extend user (e.g. in Asp.Net Identity CustomUser would implement extra interface that would require clients to implement e.g. ITenant). The UserService would have to be "aware" of this so that when implemented, it would automatically filter (get users by id, etc, etc)

Just thoughts...
zamb

from identityserver3.

I don't want any prescriptive programming model - I could imagine this:

1. IdSrv passes a "tenant" parameter (or simply all parameters) to IUserService.AuthenticateLocal
2. AuthenticateResult contains a "tenantid" (this id is preserved in the cookie)
3. id and access token contain the tenantid so subsequent access to the user service can write custom logic

The concrete implementation would be up to the IUserService and would be custom.

@brockallen what do you think?

from identityserver3.

I have what appears to be a simple requirement (not real, I've simplified what I think is my problem domain )

Given an online shop. I see two immediate user populations. Customers and Staff.

Customers should only be able to see their orders, but staff can see and manipulate all orders.

All the logic is exposed through an API and I was intending to express the above rule as a claim on the identity.

I'd like my staff to be able to authenticate via username/password (ideally WS-Fed onto ADFS) but want my customers to be able to authenticate via 'social' or local username/password.

I could setup multiple IdPs and setup the API (or other RPs) to respect these idPs (and authorize based on issuer) but I was hoping I could get away with a single IdP that could provide the constraints above. Is tenancy the approach I should be thinking of using, or is what I've talked about completely 'off the wall' ? (On IdSrv2 I was intending to use home realms to distinguish)

from identityserver3.

Here you can see my approach on code
https://github.com/ascoro/Thinktecture.IdentityServer.v3.Fork

The UserService that "support" Multitenancy implement IMultiTenantUserService

There is a client "JavascriptMultiTenantImplicitClient" to test the functionality.

from identityserver3.

OK - HRD is not fully implemented yet - right now we have local uname/password and social providers (via Katana). There is a "idp" claim in the resulting id/access token that tells you how the user logged in. From that point it is just a matter of the claims you issue.

Multi-tenancy is really something else - e.g. supporting multiple local user databases.

from identityserver3.

Ok. Thank you, in which case sorry for the noise!

from identityserver3.

@leastprivilege

I could imagine this:
1.IdSrv passes a "tenant" parameter (or simply all parameters) to IUserService.AuthenticateLocal
2.AuthenticateResult contains a "tenantid" (this id is preserved in the cookie)
3.id and access token contain the tenantid so subsequent access to the user service can write custom logic

The concrete implementation would be up to the IUserService and would be custom."

This approach would work for me. Since Membership reboot supports multi-tenant already customizing the implementation of IUserService would be fairly simple. The only other consideration seems to me is modifying either the AuthenticationController's LoginLocal post method or the LoginCredentials model. Which could be tricky because usually

• You don't want the user to have to know what you call their tenantid
• You don't want to show them a list of tenants they can choose from

so it seems that it would be better as part of the url to IdSrv. Isn't this what the hrd parameter is for more or less?

from identityserver3.

or maybe the login_hint parameter?

from identityserver3.

Yea - something like that. But we have to postpone it to a later milestone - other things are more important right now.

from identityserver3.

This will be supported via #347 and #348.

from identityserver3.

@leastprivilege IdentityServer3 have supported for multi Tenant。

from identityserver3.