SignInKey per tenant

[AlexAlexGoTO]

Which version of Duende IdentityServer are you using? 7.0 Which version of .NET are you using? 8.0

Hello, Some way I added tenantId column to Keys table, but how to use it during certificate validation? We are going to use automatic key management, I'm trying to find way to add tenantId when it creates new signin key.

As I understand I need to override ISigningKeyStore but looks like I need to override lot of other places like KeyContainer, KeyCacheStore, IAutomaticKeyManagerKeyStore, KeyManager etc...

Is there any simpler way to do it? It feels like too much work. Maybe you can recommend something else.

[RolandGuijt]

Is there a specific reason why you need to separate the keys?

It normally isn't needed and it will add complexity to your setup. Protecting APIs for example will get complex and it is also hard to validate a key per issuer as it has to be matched with the tenant id on validation.

We would recommend to use issuer or some other claim to do the separation and leave the keys as is.

[AlexAlexGoTO]

Want to ensure. Our case:

We have 1 IDP and 2 different clients. What do you mean "to use issuer claim"? Does it mean that we should make our IDP be accessible from 2 different urls(per client) and then it will have different issuers in token claims?

But what about security, one client can get the token by calling another client idp url? Or I should check domain of request?

I also have tenantId claim in my token, but how to understand in IDP that /.well-known/openid-configuration request was made with token from another tenant? Should I put tenant in url like /tenant1/.well-known/openid-configuration and then compare tenant from url with tenant from token in idp?

Maybe kinda stupid questions, but thanks in advance!

[AndersAbel]

The OpenId Connect Protocol is built around the assumption that one OpenID Provider serves multiple clients. There are mechanisms built into the protocol to ensure proper isolation between the clients.

If you have two clients using the same provider they should have different redirect uris configured, different client ids and different client secrets. That ensure that a client can only get tokens for itself, never for another client.

There are multiple ways to create a multi-tenancy solution. Without context it is impossible to do any recommendations. We are happy to aid in designing a multi tenancy solution for you as part of our remote consulting services. Please reach out to sales@duendesoftware.com for more information.

[RolandGuijt]

@AlexAlexGoTO Did the above comment answer your question? If so I would like to close this issue.

[AlexAlexGoTO]

@RolandGuijt it still not clear for 100% for me because my customers has different ids and secret, but their tokens both validated by same signin key, so each token can work with both customers, only if I validate tenantId from token body on our client's server side I can prevent this, but i'm not sure if it's correct way.

We bought Business License, currently we have only 1 active customer, but a bit later I'll try to investigate it better and text in your support if I can't find solution.

Thanks!

[RolandGuijt]

Can you tell us more about what you're trying to achieve? Do you want to issue access tokens for APIs that external customers need to access using client credentials flow? Or is it something else?

[AlexAlexGoTO]

@RolandGuijt

I tried to show whole flow on the image

[RolandGuijt]

Still not entirely clear on how this works. Are "Customer1" and "Customer2" two different applications here with their own API? Or does each customer get their own API?

[AlexAlexGoTO]

Yes, it's 2 different applications with their API, we sell product to each customer and then they setup it in their infrastructure

[RolandGuijt]

This should be solvable by using scopes:

• Configure 2 API scopes in IdentityServer. One for each API.
• In the client config for Customer1 only allow the scope for Customer1 API. The same for Customer2.
• In the clients themselves request the allowed scope.
• In the APIs be sure to check for the right scope (with an authorization policy if they use ASP.NET)'

Your tenantId check would work as well but I would use it in addition to the scopes solution. Using scopes is the way the spec is designed and will get you into a more secure situation.

[AlexAlexGoTO]

@RolandGuijt thanks! So I was close... For some reason I was thinking that it's not correct to do something like this. But this approach that you describe can totally solve my issue! Thanks a lot for your help, I'll do it this way!

[RolandGuijt]

You're welcome! Closing this issue but feel free to reopen if you want to add anything.