Hi, @JoelSpeed Are you guys interested in adding this feature to oauth2proxy anytime soon? We plan on using implementation in this PR for our internal use but we have put in extra effort to make it backward compatible & generic as we want to contribute to the community. But if this doesn't look like something that you would want to merge then we can take a private fork & maintain a custom implementation without the overhead of backward compatibility etc.
Looking forward to your response.

We are interested in this feature, but, I'm not getting much time for the project lately.

I went travelling for a few months this year and am currently mid way through a house move.

I expect I'll have time to come to this sometime mid to late January once things have settled down in my life a little bit. Apologies for the delays folks, but please do remember, this is a passion project for me, I don't get time day to day for it

I don't think we should mix tenants and providers up like this, right now, we have a single provider configuration, so the intention from previous work was that you would then have a list of providers, which is kind of what you've done, but you're calling it tenants. I'd rather we stick to a single term than mix these up.

thanks for the comment,
i can remove the "tenant" construct, so now following two new constructs will be introduced,

type TenantMatcher interface{
  GetTenantId(req *http.Request) (tenantId string, err error)
} 

type ProviderLoader interface{
// for now 'providerId' won't be used since each tenant will have only one provider but once PR #1657 is merged 'providerId' will be used
  Load(tenantId string, providerId string) (providers.Provider, error) 
}

so in a middleware, we can use TenantMatcher to get the tenantId out from http.Request, and then ProviderLoader to load the provider and inject it into request Context, so that it can be used everywhere where it is needed. What are your thoughts ?

how does it relate to existing PRs that are open? Is this an extension of those? Is it intended to replace them?

I can't find any open PRs that implement multi-tenancy. #1657 will have conflicts with this PR, but I feel they won't be huge.

Hi @JoelSpeed,

I have updated the PR to incorporate your comments. Following changes were made

1. Removed the TenantLoader interface. Now we have following constructs,

// tenantMatcher is responsible for matching tenants against incoming requests
type Matcher struct {}

// this function extracts tenantId from the request and returns it
func (matcher *Matcher) Match(req *http.Request) string {}

// ProviderLoader is responsible for getting Provider given a tenantId
type Loader interface {
	// id is provider id, which should be same as tenantId
	Load(id string) (providers.Provider, error)
}

2. Besides above constructs, I added two middlewares, one that extracts tenant-id from incoming request and injects it into request context, second that loads provider and injects it into request context.
3. Moved the new packages under the pkg/ folder.
4. There is only one configuration file now, no more configuration sharding.
5. Added tenant-id as part of SessionState.
6. Implemented a decorator/wrapper over Sessionstore interface, that inserts tenant-id in the Save(http.ResponseWrite, *http.Request, *SessionState) error function and validates that the tenant-id in the SessionState and the incoming requests same inside the Load(*http.Request) (*SessionsState, error) function.
7. Some options that were moved to different packages have been restored to original locations,
8. Cookie names now have hash of tenant-id suffixed to them. So that we log in to the different tenants from the same browser window.

Please let me know your comments.

Hello @salmanazmat666 and @JoelSpeed,

I am very interesting in this feature, therefore to participate in the effort I opend two PR on the @salmanazmat666 repository.

• Pr/1923 contrib sensysllc/oauth2-proxy#1 (Merging and start fixing tests)
• Improving support for JWT bearer token sensysllc/oauth2-proxy#2 (Adding the support for the SkipJwtBearerTokens option).

Hope this can still be integrated.

Hey @JoelSpeed,

We have added more features into the PR,

1. fixed unit tests
2. implemented a new tenantloader, that stores provider configs in postgres and uses redis as a cache to improve on latency, this also lets us add/remove providers while the proxy is running, via a REST api,
3. added context parameter to providerLoader's Load function,
4. added tenantId in CSRF cookie,

You comments are highly appreciated, please have a look at the changes and let me know what you think. Since it's a large PR we can have a call to discuss to design.

Regards,

Tremendous Job @salmanazmat666 . Do you have any sample config file or instructions to run these changes? For eg.

• sample tenants.yml file
• How to pass Postgres credentials and specific configurations
• sample alpha-config having tenantLoader and providerLoader configured
  I would appreciate it if you could provide the above details.

Tremendous Job @salmanazmat666 . Do you have any sample config file or instructions to run these changes? For eg.

• sample tenants.yml file
• How to pass Postgres credentials and specific configurations
• sample alpha-config having tenantLoader and providerLoader configured
  I would appreciate it if you could provide the above details.

Hi @adarshsingh2,
In the current state we don't need tenants.yaml, just need following alpha-config, the tenant-matcher in this config gets the tenant from a query parameter ?tid=tenant1, and the providerLoader loads the providers stored in a postgres database and uses redis as a cache, you can configure the following file according to your environment, we have implemented a REST client as well, that you can use to add/remove providers to postgres at runtime, use pkg/providerloader/postgres/NewAPIClient to get the client struct,

injectResponseHeaders:
- name: X-Forwarded-Access-Token
  values:
  - claim: access_token
- name: Authorization
  values:
  - claim: id_token
    prefix: 'Bearer '
- name: X-Auth-Request-User
  values:
  - claim: user
- name: X-Auth-Request-Email
  values:
  - claim: email
- name: X-Auth-Request-Preferred-Username
  values:
  - claim: preferred_username
- name: X-Auth-Request-Groups
  values:
  - claim: groups
- name: X-Auth-Request-Access-Token
  values:
  - claim: access_token
metricsServer:
  BindAddress: ""
  SecureBindAddress: ""
  TLS: null
providers:
  - id: tenant3
    provider: "keycloak"
    profileURL: "http://localhost:8080/auth/realms/tenant3/protocol/openid-connect/userinfo"
    validateURL: "http://localhost:8080/auth/realms/tenant3/protocol/openid-connect/userinfo"
    clientID: cmms
    clientSecret: "hf39jrh93uhd93wjd4iwj"
    scope: "openid email profile"
    loginURL: http://localhost:8080/auth/realms/tenant3/protocol/openid-connect/auth
    loginURLParameters:
    - default:
      - force
      name: approval_prompt
    oidcConfig:
      audienceClaims:
      - aud
      emailClaim: email
      groupsClaim: groups
      insecureAllowUnverifiedEmail: true
      insecureSkipIssuerVerification: true
      insecureSkipNonce: true
      issuerURL: http://localhost:8080/auth/realms/tenant3
      jwksURL: http://localhost:8080/auth/realms/tenant3/protocol/openid-connect/certs
      skipDiscovery: true
      userIDClaim: email
    redeemURL: http://localhost:8080/auth/realms/tenant3/protocol/openid-connect/token
server:
  BindAddress: 0.0.0.0:4180
  SecureBindAddress: ""
  TLS: null
tenantMatcher:
  rules:
    - source: "query"
      queryParam: "tid"
      expr: '.*'
      captureGroup: 0
providerLoader:
  type: "postgres"
  postgresLoader:
    postgres:
      host: "localhost"
      port: 5432
      database: "oauth2-proxy"
      schema: "oauth2_proxy"
      user: "admin"
      password: "admin"
      maxConnections: 50
      sslMode: "disable"
      sslRootCert: ""
      sslCrl: ""
      sslCert: ""
      sslKey: ""
    redis:
      connectionURL: "redis://localhost:6379"
      password: ""
      useSentinel: false
      sentinelPassword: ""
      sentinelMasterName: ""
      sentinelConnectionURLs:
      useCluster: false
      clusterConnectionURLs:
      cAPath: ""
      insecureSkipTLSVerify: false
      idleTimeout: 60
      expiry: 60000000000
      prefix: "oauth2-proxy-"
    aPI:
      host: "0.0.0.0"
      port: 8080
      pathPrefix: ""
      timeout: 60000000000

Hi @JoelSpeed , it would be great if you could provide feedback on the PR so that we can merge it. It been a bit difficult for us to keep this PR updated. Lets finalize a way forward if something else needs to be done. We want to merge it by end of May latest. There has been a lot of interest by community in this feature. But unfortunately due to work pressure, it won't be possible for us after May to keep this one updated & in sync with our private fork.

@salmanazmat666 happy to see you back at it

@tuunit I have updated the PR and following are the main things I did,

• - Refactoring of naming schema: tenants -> providers

• - Refactoring of package structure tenant -> providers, providerloader -> providers/loader

• - Fixing all existing unit tests

• - Check context handling in sessions.go > validateRedisSessionStore(o *options.Options)

• - Remove support for legacy (toml) flags and config. (We still have necessary config in legacy config file like cookie settings etc, so cannot remove that unless we migrate all configs to alpha.)

• Besides, I have also created files for local environment setup to demo the multi-tenancy feature, we can now use make multi-tenancy-up to bring up the necessary services that are already configured for multi-tenancy support.

• I have also templatize the cookie domains, so now we can set different domains on cookies for different tenants/providers if we want, e.g., tenant1.example.com for provider 1 and tenant2.example.com for provider 2. We could also set the domain to be .example.com for all providers but that will cause all cookies to be sent to each logged in tenant within one browser (very low chance of happening but still possible) and we might get 413 Request Too Large if too many cookies are sent in one request.

Please have a look at the changes and let me know if you want any other change.

Regards,

Thanks for putting all the work in 🥳

Thanks for putting all the work in 🥳

Hey @tuunit , did you get a chance to review the PR ?

@salmanazmat666 it might be worth making progress by merging in the base branch?

This pull request has been inactive for 60 days. If the pull request is still relevant please comment to re-activate the pull request. If no action is taken within 7 days, the pull request will be marked closed.

Hi @salmanazmat666. I'm interested in this feature too, and thank you for all your work so far!

I've given it a go, and wanted to check my understanding.

1. At the moment, am I right in thinking that every request (not just within the authentication flow) needs to be mapped to a provider, otherwise oauth2-proxy will return a 401?
2. There's currently a config provider loader and a single provider loader — could this be simplified to just the config loader with an implicit default of the first provider?

Our use case is to support multiple providers for a single upstream service, all from a single public service URL. It'd be good (at least from our perspective) if the provider can be specified as a query parameter to /oauth2/start/oauth2/sign_in and then for the provider ID to be held in OIDC state and then the session. We only protect our API's login endpoint, so requests to all other paths are unauthenticated.

I've started experimenting with adapting what you've got so far to implement the suggestion above, but don't want to go off in another direction to where you're headed. If you'd like to catch up on this that'd be great!

All the best, ~ Alex

Thank you for this amazing product and all the incredible work you've done — it's truly impressive! 🙌

Regarding multi-tenancy functionality: quite some time has passed since this idea was discussed, and it would be fantastic to see it implemented. Are there any updates on this topic?