Best way to procceed with configuring BFF for multiple apps (multiple domains) ?

[greg-signi]

Which version of Duende BFF are you using? 2.1.1

Which version of .NET are you using? 8

Best way to procceed with configuring BFF for multiple apps (multiple dashboards) ?

Should we add handlers .AddOpenIdConnect with a different client credentials multiple times for each new app (domain) we want to register, or implement a system of multi tenancy in the BFF only using 1 client to reach the IS ?

[RolandGuijt]

The BFF is meant as a companion for one particular front-end application. It is meant to be specific to that application. We recommend to create multiple BFFs in your case: one for each front-end application.

[RolandGuijt]

I'm assuming that cleared things up for you, if not feel free to re-open.

[greg-signi]

Sorry for the late response @RolandGuijt, was unreachable

I mean it would see the same application, just served on a different host. The BFF client here was the question, like if we just add multiple redirect url's to the One single Bff client, or try that approach with multiple .AddOpenIdConnect and have a lot oidc clients created.

Can you foresee any issues in this last approach ?

[AndersAbel]

Can you please elaborate a bit more on what your setup looks like? Does your BFF instance answer to multiple host names? Do you have one or more host names for your IdentityServer? Do you interact with upstream Identity Providers from your IdentityServer?

[greg-signi]

Can you please elaborate a bit more on what your setup looks like? Does your BFF instance answer to multiple host names ?

Yes, we now have the use case to answer to multiple hosts. So we need the BFF to login against the IdentityServer with different clients, because each login has to mention a different account.

We used to have one single app and one single BFF. Now we want the BFF to answer to multiple hosts (multiple copies of the same app)

The Identity Provider will always be the same for all logins, I suppose this part doesn't matter for what we are discussing.

Btw the suggestion from @RolandGuijt is not feasible in our use case, we can't have 1 bff pod for each customer, that would quickly get out of hand.

[AndersAbel]

It looks like we misunderstood the initial question in that it is not really different applications but multiple (logical) deployments of the same application to different host names.

In that case we do recommend using one BFF instance that listens to multiple host names. From the information available so far I cannot say if it would make sense to use a different ClientId for each logical host name or if it is better to use the same ClientId across all host names. That choice depends on how you deploy the OpenID Provider - does it have one issuer per tenant (i.e. one per client application) or is the same issuer used? The choice between those two options also depends on to what extent you want Single Sign On to work across tenants.

Designing a multi tenancy solution correctly is unfortunately not a trivial thing to do. There are many aspects to take into consideration both for user experience and for security.

[greg-signi]

From the information available so far I cannot say if it would make sense to use a different ClientId for each logical host name or if it is better to use the same ClientId across all host names

How do I change it per host ? You already answered me previously there were no dynamic client support. We are unsure about having only 1 client, since this forces us to change stuff in the CustomAuthorizationRequest in IdentityServer, because we don't want to add all possible redirect_uri into 1 client. Also it makes us have to override the default behaviour which is to login with the clients's account, so we somehow have pass the real account we want to login with and override it in case this field is present. And this feels like a vulnerability to us.

That choice depends on how you deploy the OpenID Provider - does it have one issuer per tenant (i.e. one per client application) or is the same issuer used? The choice between those two options also depends on to what extent you want Single Sign On to work across tenants.

It will be the same issuer everytime yes.

[josephdecock]

The BFF isn't designed to switch client id's in this way. The assumption in the BFF implementation is that there is a single OIDC client, configured as the default challenge scheme.

It might be possible to override some of the default services with custom implementations that would be aware of the tenant, but that's not something that is directly supported. A customization like that goes beyond what we can directly support on this forum.

It would be a lot easier to treat your bff as a single client. You can pass the tenant to IdentityServer using the acr_values protocol parameter (see here), which you can use during the authentication process (maybe different tenants have different user stores, or different user experiences, or some require MFA and others don't). The tenant used during authentication will be tracked in the user's session, and can be used to ensure that you isolate the tenant logins (you don't have to have single sign on when tenants are switched). You could also include the tenant in the userinfo that you pass to the BFF, and use the tenant to make authorization decisions within the BFF.

[greg-signi]

Yes this was something we were already trying it, but wanted to make sure that there was not another easiear way to do this..

The tenant used during authentication will be tracked in the user's session, and can be used to ensure that you isolate the tenant logins (you don't have to have single sign on when tenants are switched)

By this you mean we have to quit single sign on if we are doing the login with tenants ? Or requires even more work ? Not totally clear.

[josephdecock]

When the client application makes an authorize request, it can pass the desired tenant. To do so, you set the acr_values to include the tenant in the authorization request (see here).

If you pass the tenant, it will be tracked as a claim in the session, and future authorize requests can compare the requested tenant to the tenant used to log in, and if they are different, force a new login. To enable that behavior, set ValidateTenantOnAuthorization in the options.

[RolandGuijt]

@greg-signi Did Joe's comment do the trick for you? If so I'd like to close this issue.

[greg-signi]

Ok we can close it, If I've further questions on this topic I'll just use email.