Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-tenancy support for OAuth2 #5351

Closed
jzheaux opened this issue May 15, 2018 · 3 comments

Comments

@jzheaux
Copy link
Contributor

commented May 15, 2018

Summary

Today, it isn't clear how to best configure Spring Security to support a multi-tenant OAuth2 client.

Here is an example of one approach out in the wild:

https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth-example/blob/feature/mulit-tenancy/src/main/java/demo/SpringBoot2App.java#L127

Though whether JwtDecoder is the ideal place and how tenants might possibly be treated in a more first-class way is yet to be seen. Opening this issue to get the conversation started.

@jzheaux jzheaux added this to the 5.1.0.M2 milestone May 15, 2018

@bertramn

This comment has been minimized.

Copy link

commented May 18, 2018

We indeed had the requirement to run a single resource server that can validate JWTs issued by multiple issuers. We had to implement our own given the Spring one does not support this and Keycloak adapters only support Keycloak specific issuers.

We had 2 main use cases for multi tenancy:

  1. validate all inbound JWT with an Issuer whitelist

This use case requires the IssuerResolver to lookup (and cache) issuer metadata JWKS certs.

  1. validate inbound JWT based on a pre-configured list of issuers

This use case requires a pre-configured IssuerResolver which is configured with the issuer (iss) name it supports and then either the metadata url or the public cert, where the later does not really work well if your issuer performs key rotation.

Another interesting aspect we ran into was that if we just want to run a API based resource server (ie. Spring Boot micro service) there will be a lot of unnecessary moving parts in the Spring Security configuration. We ended up implementing 3 components (AccessDeniedHandler, AuthenticationFailureHandler and AuthenticationEntryPoint), everything else is surplus and massively overcomplicates things.

@jgrandja

This comment has been minimized.

Copy link
Collaborator

commented May 26, 2018

Related #5385

@jgrandja jgrandja modified the milestones: 5.1.0.M2, 5.1.0.RC1 Jul 25, 2018

@metacubed

This comment has been minimized.

Copy link

commented Aug 31, 2018

In a multi-tenant configuration, each tenant would likely come with its own set of allowed issuers. A tenant-specific request would trust only a subset of the issuers configured for the resource server.

We would need to introduce a selection mechanism to pick the allowed issuer(s) for a request. This IssuerListSelector could have custom implementations that are specific to the resource server.

For example, the keycloak-auth project uses the request.getServerName() to decide which decoder implementation to use. Other request attributes could also be used, such as the request sub-domain, a header, etc.

@jgrandja jgrandja modified the milestones: General Backlog, 5.2.x Oct 19, 2018

@jgrandja jgrandja added this to jgrandja in Security Team Oct 23, 2018

jzheaux added a commit to jzheaux/spring-security that referenced this issue Mar 29, 2019

@jzheaux jzheaux closed this in 7e8aade Mar 29, 2019

jzheaux added a commit that referenced this issue Mar 29, 2019

@jgrandja jgrandja modified the milestones: 5.2.x, 5.2.0.M2 Apr 16, 2019

@jgrandja jgrandja removed this from jgrandja in Security Team Apr 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.