Multitenant - Dynamic ClientRegistrationRepository

[andrei-vss]

Hi!

I have searched over spring security/spring authorization server/spring-oauth2-client and Stack and I got to the conclusion that what I am trying to achieve might not be possible (or not in the way I want to do it);

I am working on the next scenario (requirements):

• try to stay as close as possible to "some" standards because spring security 7 might appear at some point with breaking changes;
• without restarting the spring app to be able to add a new ClientRegistration at runtime;
• to be able to create a delegating class to select the possible ClientRegistrations (which can be multiple) for a tenant;

I am asking here cause I have seen a lot of ch4mp comments on the internet but most of them are from ~ 2 years ago. maybe there is a new perspective?

I am not using webflux.

[ch4mpy]

You'll probably have to write your own (Reactive)ClientRegistrationRepository implementation - with some care about concurrent modifications.

what I am trying to achieve might not be possible (or not in the way I want to do it)

It might be possible, but there might be easier solutions. Please tell me more about your "Multitenant" use case. Why do you need to add registrations at runtime in an OAuth2 client? How do you intend the possible ClientRegistrations to be selected? etc.

P.S.

spring-addons-starter-oidc happened to make some of the last Spring Security breaking changes transparent (and it will again for instance for the upcoming Back-Channel Logout changes in Spring 6.4 / Boot 3.4).

With Spring Boot, InMemory(Reactive)ClientRegistrationRepository creation is @ConditionalOnMissingBean((Reactive)ClientRegistrationRepository.class). So, if you expose your own (Reactive)ClientRegistrationRepository implementation as a @Bean, the default one will back off and yours will be used instead.

[andrei-vss]

thank you for the response.

I was thinking of identifying tenants by the URL.

What I wish to accomplish is a multi-tenant federator app where I could add a new tenant and his IDPs at runtime. Each tenant might have his own requirements about what identity providers he is going to use. For example, tenant 1 might use Google and Okta, while tenant 2 might choose GitHub. (I have not investigated yet but probably they should be able to also choose SAML).

I have tried to write my own ClientRegistrationRepository but it seems like spring security is calling findByRegistrationId just once at initialization.

I could register all the clients together with an InMemoryClientRegistrationRepository and use an OncePerRequestFilter to keep for each tenant the right idps, but I cannot register a new client without restarting the app or refreshing some beans (but this is something that I was referring to when I was saying I want to maintain some kind of standard);

[ch4mpy]

it seems like spring security is calling findByRegistrationId just once at initialization.

No, it is called in many places. Maybe are you referring to the controller building the login page? If that's the case, it is easy to change. And if your frontend is a single-page application, there are probably a few defaults that you should override anyway (like returning a 401 Unauthorized instead of 302 redirect to login to unauthorized requests, and handling login initiation in the SPA).

Could you please define more precisely

• What a "tenant" is for you and how do you want it to interact with your "federator app"?
• What are the expected features of this app?
• How would you determine to which tenant a user belongs?
• What would the identification flow look like for a user?

[sebutzu]

Hi, i am working with @andrei-vss on this. I will try to give more details:
A "tenant" is a "customer", that needs to have its own data. Also a customer needs to have its own login mechanisms defined when is created (which needs to be at runtime). Like for customer 1 he will use login with username and password, for customer 2 he will use login with google and github, but no username and pass, for customer 3 he will use login with saml or google (but a different google user and secret than customer 2), etc.
In the main application (which is a Spring Cloud Gateway acting as BFF), there will be links containing customer id for each page in the frontend.
So if a user goes to /customer1/index.html and is not authenticated, he should jump into "federator" (which is a Spring Authorization Server), on the customer1 issuer (we use multiple issuers).
Another way to "login" would be for the user to go to a url like "customer1/login" directly in "federator" aka Authorization Server.
Each customer has it's own users.

So because of the need to be able to add customers at runtime, and because each customer has it's own ClientRegistrations, we need to be able to also add those at runtime.

Hope this makes it more clear.

[ch4mpy]

If you haven't read this article already, you should. In the solution I built there, I expose a controller endpoint on the BFF with all the "login options" it supports (one per registration with authorization_code).

This list is static, but you could adapt it easily once you have written a mutable
ReactiveClientRegistrationRepository (again, be careful to make your implementation thread-safe). Of course, instead of building the list in the constructor like I did, you should re-evaluate it each time the login options are queried.

The same controller would probably have another endpoint to create the new "tenants" (add registrations - and optionally providers - to the mutable repo).

From the frontend point of view (whatever uses this OAuth2 BFF to call your REST API), what is required to log a user in is:

• fetch login options from the gateway
• pick one of these options based on something (prompt the user to select one, or better, infer it from the context of the current route or whatever)
• redirect the user agent to the selected option (a URI on the gateway containing the chosen registration ID, which will respond with a redirection to the authorization server authorization_endpoint, etc.)

To save some resources, I'd try to find a way to skip the first step (fetching all login options), as it should be possible to infer the authorization initiation URI for a given "tenant" (the only changing part is the registration ID which could be predictable for a given tenant).

Regarding the various user identification flows, this should be handled by the authorization server. For that, I'd use a unique {issuer, clientId} pair for each tenant, and configure the desired flow and social login options for each. This gives you the options to define different registrations (which holds the clientId) sharing the same provider (issuer), or to isolate each tenant with its own provider.

P.S.

So far, I always preferred theming Keycloak (or a cloud offering like Auth0 when the team didn't have the resources to administer an on-premise solution 24/7) than creating an authorization server with user account management, OAuth2 clients management, social login, identity federation, and fancy stuff like "magic-link" or multi-factor authentication. But that's another story.

[ch4mpy]

@andrei-vss , @sebutzu please Mark as answer or comment why it does not answer.