Using OpenID Connect (OIDC) multitenancy

本指南演示您的开放 ID 连接 (OIDC) 应用程序如何支持多租户，以便于从一个应用程序为多个租户提供服务。这些租户可以在同一个 OIDC 提供商内是不同的领域或安全域，甚至是不同的 OIDC 提供商。

This guide demonstrates how your OpenID Connect (OIDC) application can support multitenancy to serve multiple tenants from a single application. These tenants can be distinct realms or security domains within the same OIDC provider or even distinct OIDC providers.

在从同一个应用程序中为多个客户提供服务时，例如在 SaaS 环境中，每个客户都作为一个不同的租户运行。通过为您的应用程序启用多租户支持，您可以为每个租户支持不同的认证策略，甚至可以针对不同的 OIDC 提供商（如 Keycloak 和 Google）进行认证。

Each customer functions as a distinct tenant when serving multiple customers from the same application, such as in a SaaS environment. By enabling multitenancy support to your applications, you can support distinct authentication policies for each tenant, even authenticating against different OIDC providers, such as Keycloak and Google.

若要使用 Bearer 令牌授权认证租户，请参阅 OpenID Connect (OIDC) Bearer token authentication 指南。

To authorize a tenant by using Bearer Token Authorization, see the OpenID Connect (OIDC) Bearer token authentication guide.

若要使用 OIDC 授权代码流认证并授权租户，请阅读 OpenID Connect authorization code flow mechanism for protecting web applications 指南。

To authenticate and authorize a tenant by using the OIDC authorization code flow, read the OpenID Connect authorization code flow mechanism for protecting web applications guide.

此外，请参阅 OpenID Connect (OIDC) configuration properties 参考指南。

Also, see the OpenID Connect (OIDC) configuration properties reference guide.

Prerequisites

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/prerequisites.adoc[]* jq tool

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/prerequisites.adoc[] * jq tool

Architecture

在此示例中，我们构建了一个非常简单的应用程序，该应用程序支持两种资源方法：

In this example, we build a very simple application that supports two resource methods:

  • /{tenant}

此资源返回 OIDC 提供者签发给经验证用户和当前租户的 ID 令牌中获得的信息。

This resource returns information obtained from the ID token issued by the OIDC provider about the authenticated user and the current tenant.

  • /{tenant}/bearer

此资源将返回由 OIDC 提供程序针对已验证用户和当前租户发出的访问令牌中获取的信息。

This resource returns information obtained from the Access Token issued by the OIDC provider about the authenticated user and the current tenant.

Solution

为了透彻地了解，我们建议您按照即将提供的分步说明构建该应用程序。

For a thorough understanding, we recommend you build the application by following the upcoming step-by-step instructions.

另外，如果您希望从完成的示例入手，请克隆 Git 存储库：git clone {quickstarts-clone-url}，或下载一个 {quickstarts-archive-url}[归档文档]。

Alternatively, if you prefer to start with the completed example, clone the Git repository: git clone {quickstarts-clone-url}, or download an {quickstarts-archive-url}[archive].

该解决方案位于 security-openid-connect-multi-tenancy-quickstart directory中。

The solution is located in the security-openid-connect-multi-tenancy-quickstart directory.

Creating the Maven project

首先，我们需要一个新项目。使用以下命令创建一个新项目：

First, we need a new project. Create a new project with the following command:

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/devtools/create-app.adoc[]

如果您已经配置了 Quarkus 项目，请通过在项目基本目录中运行以下命令将 `oidc`扩展添加到您的项目中：

If you already have your Quarkus project configured, add the oidc extension to your project by running the following command in your project base directory:

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/devtools/extension-add.adoc[]

这将把以下内容添加到您的构建文件中：

This adds the following to your build file:

pom.xml
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-oidc</artifactId>
</dependency>
build.gradle
implementation("io.quarkus:quarkus-oidc")

Writing the application

首先，实现 `/{tenant}`端点。正如您从以下源代码中所看到的，它只是一个常规 Jakarta REST 资源：

Start by implementing the /{tenant} endpoint. As you can see from the source code below, it is just a regular Jakarta REST resource:

package org.acme.quickstart.oidc;

import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;

import org.eclipse.microprofile.jwt.JsonWebToken;

import io.quarkus.oidc.IdToken;

@Path("/{tenant}")
public class HomeResource {
    /**
     * Injection point for the ID Token issued by the OIDC provider.
     */
    @Inject
    @IdToken
    JsonWebToken idToken;

    /**
     * Injection point for the Access Token issued by the OIDC provider.
     */
    @Inject
    JsonWebToken accessToken;

    /**
     * Returns the ID Token info.
     * This endpoint exists only for demonstration purposes.
     * Do not expose this token in a real application.
     *
     * @return ID Token info
     */
    @GET
    @Produces("text/html")
    public String getIdTokenInfo() {
        StringBuilder response = new StringBuilder().append("<html>")
                .append("<body>");

        response.append("<h2>Welcome, ").append(this.idToken.getClaim("email").toString()).append("</h2>\n");
        response.append("<h3>You are accessing the application within tenant <b>").append(idToken.getIssuer()).append(" boundaries</b></h3>");

        return response.append("</body>").append("</html>").toString();
    }

    /**
     * Returns the Access Token info.
     * This endpoint exists only for demonstration purposes.
     * Do not expose this token in a real application.
     *
     * @return Access Token info
     */
    @GET
    @Produces("text/html")
    @Path("bearer")
    public String getAccessTokenInfo() {
        StringBuilder response = new StringBuilder().append("<html>")
                .append("<body>");

        response.append("<h2>Welcome, ").append(this.accessToken.getClaim("email").toString()).append("</h2>\n");
        response.append("<h3>You are accessing the application within tenant <b>").append(accessToken.getIssuer()).append(" boundaries</b></h3>");

        return response.append("</body>").append("</html>").toString();
    }
}

若要从传入请求中解析租户并将它映射到 `application.properties`中的特定 `quarkus-oidc`租户配置，请为 `io.quarkus.oidc.TenantConfigResolver`接口创建一个实现，它可以动态解析租户配置：

To resolve the tenant from incoming requests and map it to a specific quarkus-oidc tenant configuration in application.properties, create an implementation for the io.quarkus.oidc.TenantConfigResolver interface, which can dynamically resolve tenant configurations:

package org.acme.quickstart.oidc;

import jakarta.enterprise.context.ApplicationScoped;

import org.eclipse.microprofile.config.ConfigProvider;

import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.OidcTenantConfig.ApplicationType;
import io.quarkus.oidc.TenantConfigResolver;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantResolver implements TenantConfigResolver {

    @Override
    public Uni<OidcTenantConfig> resolve(RoutingContext context, OidcRequestContext<OidcTenantConfig> requestContext) {
        String path = context.request().path();

        if (path.startsWith("/tenant-a")) {
           String keycloakUrl = ConfigProvider.getConfig().getValue("keycloak.url", String.class);

            OidcTenantConfig config = new OidcTenantConfig();
            config.setTenantId("tenant-a");
            config.setAuthServerUrl(keycloakUrl + "/realms/tenant-a");
            config.setClientId("multi-tenant-client");
            config.getCredentials().setSecret("secret");
            config.setApplicationType(ApplicationType.HYBRID);
            return Uni.createFrom().item(config);
        } else {
            // resolve to default tenant config
            return Uni.createFrom().nullItem();
        }
    }
}

在前述实现中，租户将从请求路径中解析。如果无法推断出任何租户，则返回 `null`以指示应使用默认租户配置。

In the preceding implementation, tenants are resolved from the request path. If no tenant can be inferred, null is returned to indicate that the default tenant configuration should be used.

tenant-a`应用程序的类型是 `hybrid；如果提供了 HTTP 持久令牌，它可以接受 HTTP 持久令牌。否则，它会在需要验证时启动授权代码流程。

The tenant-a application type is hybrid; it can accept HTTP bearer tokens if provided. Otherwise, it initiates an authorization code flow when authentication is required.

Configuring the application

# Default tenant configuration
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=multi-tenant-client
quarkus.oidc.application-type=web-app

# Tenant A configuration is created dynamically in CustomTenantConfigResolver

# HTTP security configuration
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

第一个配置是默认租户配置，当无法从请求中推断出租户时应使用该配置。请注意，在 `quarkus.oidc.auth-server-url`中使用了 `%prod`配置文件前缀，以支持使用 Keycloak 的 Dev Services 测试多租户应用程序。该配置使用 Keycloak 实例对用户进行验证。

The first configuration is the default tenant configuration that should be used when the tenant cannot be inferred from the request. Be aware that a %prod profile prefix is used with quarkus.oidc.auth-server-url to support testing a multitenant application with Dev Services For Keycloak. This configuration uses a Keycloak instance to authenticate users.

当传入请求映射到 `tenant-a`租户时，使用 `TenantConfigResolver`提供的第二个配置。

The second configuration, provided by TenantConfigResolver, is used when an incoming request is mapped to the tenant-a tenant.

这两个配置都映射到同一个 Keycloak 服务器实例，同时使用不同的 realms。

Both configurations map to the same Keycloak server instance while using distinct realms.

另外，您可以直接在 application.properties`中配置租户 `tenant-a：

Alternatively, you can configure the tenant tenant-a directly in application.properties:

# Default tenant configuration
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=multi-tenant-client
quarkus.oidc.application-type=web-app

# Tenant A configuration
quarkus.oidc.tenant-a.auth-server-url=http://localhost:8180/realms/tenant-a
quarkus.oidc.tenant-a.client-id=multi-tenant-client
quarkus.oidc.tenant-a.application-type=web-app

# HTTP security configuration
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

在这种情况下，还要使用自定义 `TenantConfigResolver`进行解析：

In that case, also use a custom TenantConfigResolver to resolve it:

package org.acme.quickstart.oidc;

import jakarta.enterprise.context.ApplicationScoped;

import io.quarkus.oidc.TenantResolver;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantResolver implements TenantResolver {

    @Override
    public String resolve(RoutingContext context) {
        String path = context.request().path();
        String[] parts = path.split("/");

        if (parts.length == 0) {
            //Resolve to default tenant configuration
            return null;
        }

        return parts[1];
    }
}

您可以在配置文件中定义多个租户。在从 `TenantResolver`实现中解析租户时将它们正确映射，请确保每个租户都具有唯一别名。

You can define multiple tenants in your configuration file. To map them correctly when resolving a tenant from your TenantResolver implementation, ensure each has a unique alias.

但是，使用静态租户解析，具体涉及在 `application.properties`中配置租户并在 `TenantResolver`中解析它们，不适用于与 Dev Services for Keycloak 共同测试端点，因为它不知道如何将请求映射至各租户，也无法动态提供租户特定的 `quarkus.oidc.<tenant-id>.auth-server-url`值。因此，在测试和开发模式下，在 `application.properties`中使用具有租户特定 URL 的 `%prod`前缀都不起作用。

However, using a static tenant resolution, which involves configuring tenants in application.properties and resolving them with TenantResolver, does not work for testing endpoints with Dev Services for Keycloak because it does not know how the requests are be mapped to individual tenants, and cannot dynamically provide tenant-specific quarkus.oidc.<tenant-id>.auth-server-url values. Therefore, using %prod prefixes with tenant-specific URLs within application.properties does not work in both test and development modes.

当当前租户表示 OIDC `web-app`应用程序时，当为所有请求完成代码验证流程并且已验证请求，或者当租户特定的状态或会话 Cookie 已经存在时，在为所有请求调用自定义租户解析器之前，当前 `io.vertx.ext.web.RoutingContext`包含一个 `tenant-id`属性。因此，在使用多个 OIDC 提供程序时，如果您希望解析租户 ID，只需一个特定于路径的检查，如果 `RoutingContext`未设置 `tenant-id`属性，例如：

When a current tenant represents an OIDC web-app application, the current io.vertx.ext.web.RoutingContext contains a tenant-id attribute by the time the custom tenant resolver has been called for all the requests completing the code authentication flow and the already authenticated requests, when either a tenant-specific state or session cookie already exists. Therefore, when working with multiple OIDC providers, you only need a path-specific check to resolve a tenant id if the RoutingContext does not have the tenant-id attribute set, for example:

package org.acme.quickstart.oidc;

import jakarta.enterprise.context.ApplicationScoped;

import io.quarkus.oidc.TenantResolver;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantResolver implements TenantResolver {

    @Override
    public String resolve(RoutingContext context) {
        String tenantId = context.get("tenant-id");
        if (tenantId != null) {
            return tenantId;
        } else {
            // Initial login request
            String path = context.request().path();
            String[] parts = path.split("/");

            if (parts.length == 0) {
                //Resolve to default tenant configuration
                return null;
            }
            return parts[1];
        }
    }
}

这是 Quarkus OIDC 在未注册任何自定义 `TenantResolver`的情况下解析静态自定义租户的方式。

This is how Quarkus OIDC resolves static custom tenants if no custom TenantResolver is registered.

类似的技术也可与 `TenantConfigResolver`一起使用，其中 `tenant-id`提供的 `OidcTenantConfig`可在准备好上一个请求后返回。

A similar technique can be used with TenantConfigResolver, where a tenant-id provided in the context can return OidcTenantConfig already prepared with the previous request.

如果你还要使用 Hibernate ORM multitenancy或 MongoDB with Panache multitenancy，并且两个租户 Id 相同且必须从 Vert.x `RoutingContext`中提取，那么你可以将租户 Id 从 OIDC 租户解析器传递到 Hibernate ORM 租户解析器或 MongoDB 及 Panache Mongo 数据库解析器，作为一个 `RoutingContext`属性，例如：

If you also use Hibernate ORM multitenancy or MongoDB with Panache multitenancy and both tenant ids are the same and must be extracted from the Vert.x RoutingContext, you can pass the tenant id from the OIDC Tenant Resolver to the Hibernate ORM Tenant Resolver or MongoDB with Panache Mongo Database Resolver as a RoutingContext attribute, for example:

public class CustomTenantResolver implements TenantResolver {

    @Override
    public String resolve(RoutingContext context) {
        String tenantId = extractTenantId(context);
        context.put("tenantId", tenantId);
        return tenantId;
    }
}

Starting and configuring the Keycloak server

要启动 Keycloak 服务器，可以使用 Docker 并运行以下命令：

To start a Keycloak server, you can use Docker and run the following command:

docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev

其中 `keycloak.version`被设置为 `25.0.2`或更高版本。

where keycloak.version is set to 25.0.2 or higher.

在 localhost:8180访问你的 Keycloak 服务器。

Access your Keycloak server at localhost:8180.

以 admin`用户身份登陆以访问 Keycloak 管理控制台。用户名和密码都是 `admin。

Log in as the admin user to access the Keycloak administration console. The username and password are both admin.

现在，为这两个租户导入国度：

Now, import the realms for the two tenants:

有关如何 create a new realm的更多信息，请参阅 Keycloak 文档。

For more information, see the Keycloak documentation about how to create a new realm.

Running and using the application

Running in developer mode

要在 dev 模式中运行微服务，请使用：

To run the microservice in dev mode, use:

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/devtools/dev.adoc[]

Running in JVM mode

在 dev 模式下探索应用程序后，您可以将其作为标准 Java 应用程序运行。

After exploring the application in dev mode, you can run it as a standard Java application.

首先，对其进行编译：

First, compile it:

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/devtools/build.adoc[]

然后运行它：

Then run it:

java -jar target/quarkus-app/quarkus-run.jar

Running in native mode

可以将相同的演示编译成本机代码，无需改动。

This same demo can be compiled into native code; no modifications are required.

这意味着你不再需要在产品环境中安装 JVM，因为运行时技术包含在生成的可执行文件中，并且经过优化，可以使用更少的资源运行。

This implies that you no longer need to install a JVM on your production environment, as the runtime technology is included in the produced binary, and optimized to run with minimal resources.

编译需要花费更多时间，因此默认情况下此步骤被关闭；通过启用本机构建，让我们重新构建：

Compilation takes a bit longer, so this step is turned off by default; let’s build again by enabling the native build:

Unresolved directive in security-openid-connect-multitenancy.adoc - include::{includes}/devtools/build-native.adoc[]

过一会儿，你可以直接运行此可执行文件：

After a little while, you can run this binary directly:

./target/security-openid-connect-multi-tenancy-quickstart-runner

Test the application

Use Dev Services for Keycloak

对于针对 Keycloak 的集成测试来说，Dev Services for Keycloak 是推荐的。Keycloak 的 Dev Services 启动并初始化一个测试容器：它会导入已配置的国度，并为 `CustomTenantResolver`设置一个基本的 Keycloak URL 以计算特定于领域的 URL。

Dev Services for Keycloak is recommended for the integration testing against Keycloak. Dev Services for Keycloak launches and initializes a test container: it imports configured realms and sets a base Keycloak URL for the CustomTenantResolver to calculate a realm-specific URL.

首先，添加下列依赖项：

First, add the following dependencies:

pom.xml
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-test-keycloak-server</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.htmlunit</groupId>
    <artifactId>htmlunit</artifactId>
    <scope>test</scope>
</dependency>
build.gradle
testImplementation("io.quarkus:quarkus-test-keycloak-server")
testImplementation("io.rest-assured:rest-assured")
testImplementation("org.htmlunit:htmlunit")

quarkus-test-keycloak-server`提供了一个实用类 `io.quarkus.test.keycloak.client.KeycloakTestClient，用于获取特定于领域的访问令牌，并且你可以使用 `RestAssured`来测试期望持有者访问令牌的 `/{tenant}/bearer`端点。`HtmlUnit`测试 `/{tenant}`端点和授权代码流。

quarkus-test-keycloak-server provides a utility class io.quarkus.test.keycloak.client.KeycloakTestClient for acquiring the realm specific access tokens and which you can use with RestAssured for testing the /{tenant}/bearer endpoint expecting bearer access tokens. HtmlUnit tests the /{tenant} endpoint and the authorization code flow.

接下来，配置所需的领域：

Next, configure the required realms:

# Default tenant configuration
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=multi-tenant-client
quarkus.oidc.application-type=web-app

# Tenant A configuration is created dynamically in CustomTenantConfigResolver

# HTTP security configuration
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

quarkus.keycloak.devservices.realm-path=default-tenant-realm.json,tenant-a-realm.json

最后，编写以 JVM 模式运行的测试：

Finally, write your test, which runs in JVM mode:

package org.acme.quickstart.oidc;

import static org.hamcrest.Matchers.containsString;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;

import java.io.IOException;

import org.htmlunit.SilentCssErrorHandler;
import org.htmlunit.WebClient;
import org.htmlunit.html.HtmlForm;
import org.htmlunit.html.HtmlPage;
import org.junit.jupiter.api.Test;

import io.quarkus.test.junit.QuarkusTest;
import io.quarkus.test.keycloak.client.KeycloakTestClient;
import io.restassured.RestAssured;

@QuarkusTest
public class CodeFlowTest {

    KeycloakTestClient keycloakClient = new KeycloakTestClient();

    @Test
    public void testLogInDefaultTenant() throws IOException {
        try (final WebClient webClient = createWebClient()) {
            HtmlPage page = webClient.getPage("http://localhost:8081/default");

            assertEquals("Sign in to quarkus", page.getTitleText());

            HtmlForm loginForm = page.getForms().get(0);

            loginForm.getInputByName("username").setValueAttribute("alice");
            loginForm.getInputByName("password").setValueAttribute("alice");

            page = loginForm.getInputByName("login").click();

            assertTrue(page.asText().contains("tenant"));
        }
    }

    @Test
    public void testLogInTenantAWebApp() throws IOException {
        try (final WebClient webClient = createWebClient()) {
            HtmlPage page = webClient.getPage("http://localhost:8081/tenant-a");

            assertEquals("Sign in to tenant-a", page.getTitleText());

            HtmlForm loginForm = page.getForms().get(0);

            loginForm.getInputByName("username").setValueAttribute("alice");
            loginForm.getInputByName("password").setValueAttribute("alice");

            page = loginForm.getInputByName("login").click();

            assertTrue(page.asText().contains("alice@tenant-a.org"));
        }
    }

    @Test
    public void testLogInTenantABearerToken() throws IOException {
        RestAssured.given().auth().oauth2(getAccessToken()).when()
            .get("/tenant-a/bearer").then().body(containsString("alice@tenant-a.org"));
    }

    private String getAccessToken() {
        return keycloakClient.getRealmAccessToken("tenant-a", "alice", "alice", "multi-tenant-client", "secret");
    }

    private WebClient createWebClient() {
        WebClient webClient = new WebClient();
        webClient.setCssErrorHandler(new SilentCssErrorHandler());
        return webClient;
    }
}

以本机模式：

In native mode:

package org.acme.quickstart.oidc;

import io.quarkus.test.junit.QuarkusIntegrationTest;

@QuarkusIntegrationTest
public class CodeFlowIT extends CodeFlowTest {
}

有关其如何初始化和配置的更多信息，请参阅 Dev Services for Keycloak。

For more information about how it is initialized and configured, see Dev Services for Keycloak.

Use the browser

要测试应用程序，请打开浏览器并访问以下 URL：

To test the application, open your browser and access the following URL:

如果一切都如预期的那样正常工作，将会重定向到 Keycloak 服务器进行身份验证。请注意，请求的路径定义了一个 `default`租户，我们在配置文件中没有映射它。在这种情况下，将使用默认配置。

If everything works as expected, you are redirected to the Keycloak server to authenticate. Be aware that the requested path defines a default tenant, which we don’t have mapped in the configuration file. In this case, the default configuration is used.

要对应用程序进行身份验证，请在 Keycloak 登录页面中输入以下凭据：

To authenticate to the application, enter the following credentials in the Keycloak login page:

  • Username: alice

  • Password: alice

单击 *Login*按钮后，您将被重定向回该应用程序。

After clicking the Login button, you are redirected back to the application.

如果您现在尝试通过以下 URL 访问该应用程序：

If you try now to access the application at the following URL:

您将再次被重定向到 Keycloak 登录页面。但是，这次您将使用不同的领域进行身份验证。

You are redirected again to the Keycloak login page. However, this time, you are going to authenticate by using a different realm.

在这两种情况下，如果用户成功通过身份验证，则登录页面将显示用户的姓名和电子邮件。尽管 `alice`存在于两个租户中，但应用程序将它们视为不同领域中的不同用户。

In both cases, the landing page shows the user’s name and email if the user is successfully authenticated. Although alice exists in both tenants, the application treats them as distinct users in separate realms.

Tenant resolution

Tenant resolution order

OIDC 租户按以下顺序解析：

OIDC tenants are resolved in the following order:

  1. io.quarkus.oidc.Tenant annotation is checked first if the proactive authentication is disabled.

  2. Dynamic tenant resolution using a custom TenantConfigResolver.

  3. Static tenant resolution using one of these options: custom TenantResolver, configured tenant paths, and defaulting to the last request path segment as a tenant id.

最后，如果在前面的步骤后仍未解析出租户 ID，则将选择默认 OIDC 租户。

Finally, the default OIDC tenant is selected if a tenant id has not been resolved after the preceeding steps.

有关更多信息，请参阅以下部分：

See the following sections for more information:

此外，对于 OIDC `web-app`应用程序，状态和会话 Cookie 还会提供在授权代码流开始时使用上述选项之一解析的租户的提示。有关更多信息，请参阅 Tenant resolution for OIDC web-app applications部分。

Additionally, for the OIDC web-app applications, the state and session cookies also provide a hint about the tenant resolved with one of the above mentioned options at the time when the authorization code flow started. See the Tenant resolution for OIDC web-app applications section for more information.

Resolve with annotations

您可以使用 `io.quarkus.oidc.Tenant`注释来解析租户标识符，作为使用 `io.quarkus.oidc.TenantResolver`的替代方法。

You can use the io.quarkus.oidc.Tenant annotation for resolving the tenant identifiers as an alternative to using io.quarkus.oidc.TenantResolver.

必须禁用主动 HTTP 身份验证 (quarkus.http.auth.proactive=false)，此方法才有效。有关详细信息，请参阅 Proactive authentication指南。

Proactive HTTP authentication must be disabled (quarkus.http.auth.proactive=false) for this to work. For more information, see the Proactive authentication guide.

假设您的应用程序支持两个 OIDC 租户，即 `hr`和默认租户，那么所有带 `@Tenant("hr")`的资源方法和类均由 `quarkus.oidc.hr.auth-server-url`配置的 OIDC 提供程序进行验证。与此相反，所有其他类和方法仍由默认 OIDC 提供程序进行验证。

Assuming your application supports two OIDC tenants, the hr and default tenants, all resource methods and classes carrying @Tenant("hr") are authenticated by using the OIDC provider configured by quarkus.oidc.hr.auth-server-url. In contrast, all other classes and methods are still authenticated by using the default OIDC provider.

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

import io.quarkus.oidc.Tenant;
import io.quarkus.security.Authenticated;

@Authenticated
@Path("/api/hello")
public class HelloResource {

    @Tenant("hr") 1
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String sayHello() {
        return "Hello!";
    }
}
1 The io.quarkus.oidc.Tenant annotation must be placed on either the resource class or resource method.

在上面的示例中，`sayHello`端点的验证通过 `@Authenticated`注释执行。或者，如果您使用 HTTP Security policy保护端点，则要想 `@Tenant`注释生效，您必须延迟此策略的许可检查，如下面的示例所示：

In the example above, authentication of the sayHello endpoint is enforced with the @Authenticated annotation. Alternatively, if you use an the HTTP Security policy to secure the endpoint, then, for the @Tenant annotation be effective, you must delay this policy’s permission check as shown in the example below:

quarkus.http.auth.permission.authenticated.paths=/api/hello
quarkus.http.auth.permission.authenticated.methods=GET
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.http.auth.permission.authenticated.applies-to=JAXRS 1
1 Tell Quarkus to run the HTTP permission check after the tenant has been selected with the @Tenant annotation.

Dynamic tenant configuration resolution

如果您需要对想要支持的不同租户进行更动态的配置，并且不想在配置文件中有多个条目，您可以使用 io.quarkus.oidc.TenantConfigResolver。

If you need a more dynamic configuration for the different tenants you want to support and don’t want to end up with multiple entries in your configuration file, you can use the io.quarkus.oidc.TenantConfigResolver.

此界面允许您在运行时动态创建租户配置：

This interface allows you to dynamically create tenant configurations at runtime:

package io.quarkus.it.keycloak;

import jakarta.enterprise.context.ApplicationScoped;
import java.util.function.Supplier;

import io.smallrye.mutiny.Uni;
import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.TenantConfigResolver;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantConfigResolver implements TenantConfigResolver {

    @Override
    public Uni<OidcTenantConfig> resolve(RoutingContext context, OidcRequestContext<OidcTenantConfig> requestContext) {
        String path = context.request().path();
        String[] parts = path.split("/");

        if (parts.length == 0) {
            //Resolve to default tenant configuration
            return null;
        }

        if ("tenant-c".equals(parts[1])) {
            // Do 'return requestContext.runBlocking(createTenantConfig());'
            // if a blocking call is required to create a tenant config,
            return Uni.createFromItem(createTenantConfig());
        }

        //Resolve to default tenant configuration
        return null;
    }

    private Supplier<OidcTenantConfig> createTenantConfig() {
        final OidcTenantConfig config = new OidcTenantConfig();

        config.setTenantId("tenant-c");
        config.setAuthServerUrl("http://localhost:8180/realms/tenant-c");
        config.setClientId("multi-tenant-client");
        OidcTenantConfig.Credentials credentials = new OidcTenantConfig.Credentials();

        credentials.setSecret("my-secret");

        config.setCredentials(credentials);

        // Any other setting supported by the quarkus-oidc extension

        return () -> config;
    }
}

此方法返回的 `OidcTenantConfig`与用于从 `application.properties`解析 `oidc`命名空间配置的 `OidcTenantConfig`相同。您可以使用 `quarkus-oidc`扩展支持的任何设置来填充该命名空间配置。

The OidcTenantConfig returned by this method is the same one used to parse the oidc namespace configuration from the application.properties. You can populate it by using any settings supported by the quarkus-oidc extension.

如果动态租户解析器返回 null，接下来将尝试 Static tenant configuration resolution。

If the dynamic tenant resolver returns null, a Static tenant configuration resolution is attempted next.

Static tenant configuration resolution

当您在 `application.properties`文件中设置多个租户配置时，您只需指定如何解析租户标识符即可。要配置租户标识符解析，请使用以下选项之一：

When you set multiple tenant configurations in the application.properties file, you only need to specify how the tenant identifier gets resolved. To configure the resolution of the tenant identifier, use one of the following options:

这些租户解析选项将按列出的顺序进行尝试，直到租户 ID 得到解析。如果租户 ID 仍未解析 (null)，则选择默认（未命名）租户配置。

These tenant resolution options are tried in the order they are listed until the tenant id gets resolved. If the tenant id remains unresolved (null), the default (unnamed) tenant configuration is selected.

Resolve with TenantResolver

以下 `application.properties`示例展示了如何使用 `TenantResolver`方法解析名为 `a`和 `b`的两个租户的租户标识符：

The following application.properties example shows how you can resolve the tenant identifier of two tenants named a and b by using the TenantResolver method:

# Tenant 'a' configuration
quarkus.oidc.a.auth-server-url=http://localhost:8180/realms/quarkus-a
quarkus.oidc.a.client-id=client-a
quarkus.oidc.a.credentials.secret=client-a-secret

# Tenant 'b' configuration
quarkus.oidc.b.auth-server-url=http://localhost:8180/realms/quarkus-b
quarkus.oidc.b.client-id=client-b
quarkus.oidc.b.credentials.secret=client-b-secret

您可以从 `quarkus.oidc.TenantResolver`返回 `a`或 `b`的租户 ID：

You can return the tenant id of either a or b from quarkus.oidc.TenantResolver:

import quarkus.oidc.TenantResolver;

public class CustomTenantResolver implements TenantResolver {

    @Override
    public String resolve(RoutingContext context) {
        String path = context.request().path();
        if (path.endsWith("a")) {
            return "a";
        } else if (path.endsWith("b")) {
            return "b";
        } else {
            // default tenant
            return null;
        }
    }
}

在此示例中，最后请求路径段的值是租户 ID，但如果需要，您可以实现更复杂的租户标识符解析逻辑。

In this example, the value of the last request path segment is a tenant id, but if required, you can implement a more complex tenant identifier resolution logic.

Configure tenant paths

作为使用 `io.quarkus.oidc.TenantResolver`的替代方法，您可以使用 `quarkus.oidc.tenant-paths`配置属性来解析租户标识符。以下是为上一个示例中使用的 `HelloResource`资源的 `sayHello`端点选择 `hr`租户的方法：

You can use the quarkus.oidc.tenant-paths configuration property for resolving the tenant identifier as an alternative to using io.quarkus.oidc.TenantResolver. Here is how you can select the hr tenant for the sayHello endpoint of the HelloResource resource used in the previous example:

quarkus.oidc.hr.tenant-paths=/api/hello 1
quarkus.oidc.a.tenant-paths=/api/* 2
quarkus.oidc.b.tenant-paths=/*/hello 3
1 Same path-matching rules apply as for the quarkus.http.auth.permission.authenticated.paths=/api/hello configuration property from the previous example.
2 The wildcard placed at the end of the path represents any number of path segments. However the path is less specific than the /api/hello, therefore the hr tenant will be used to secure the sayHello endpoint.
3 The wildcard in the /*/hello represents exactly one path segment. Nevertheless, the wildcard is less specific than the api, therefore the hr tenant will be used.

路径匹配机制的工作原理与 Authorization using configuration中完全相同。

Path-matching mechanism works exactly same as in the Authorization using configuration.

Use last request path segment as tenant id

租户标识符的默认解析基于约定，即身份验证请求必须在请求路径的最后一段中包含租户标识符。

The default resolution for a tenant identifier is convention based, whereby the authentication request must include the tenant identifier in the last segment of the request path.

以下 application.properties 示例展示了如何为 google 和 github 配置两个租户：

The following application.properties example shows how you can configure two tenants named google and github:

# Tenant 'google' configuration
quarkus.oidc.google.provider=google
quarkus.oidc.google.client-id=${google-client-id}
quarkus.oidc.google.credentials.secret=${google-client-secret}
quarkus.oidc.google.authentication.redirect-path=/signed-in

# Tenant 'github' configuration
quarkus.oidc.github.provider=google
quarkus.oidc.github.client-id=${github-client-id}
quarkus.oidc.github.credentials.secret=${github-client-secret}
quarkus.oidc.github.authentication.redirect-path=/signed-in

在提供的示例中，两个租户均配置 OIDC web-app 应用程序，使用授权代码流对用户进行身份验证并要求在身份验证后生成会话 Cookie。在 Google 或 GitHub 对当前用户进行身份验证后，用户将返回到 /signed-in 区域（如 JAX-RS 端点上的安全资源路径）以供经过身份验证的用户使用。

In the provided example, both tenants configure OIDC web-app applications to use an authorization code flow to authenticate users and require session cookies to be generated after authentication. After Google or GitHub authenticates the current user, the user gets returned to the /signed-in area for authenticated users, such as a secured resource path on the JAX-RS endpoint.

最后，为完成默认租户解析，请设置以下配置属性：

Finally, to complete the default tenant resolution, set the following configuration property:

quarkus.http.auth.permission.login.paths=/google,/github
quarkus.http.auth.permission.login.policy=authenticated

如果端点正在 http://localhost:8080 中运行，则还可以为用户提供 UI 选项，让他们登录到 http://localhost:8080/google 或 http://localhost:8080/github，无需添加特定的 /google 或 /github JAX-RS 资源路径。在身份验证完成之后，租户标识符也会记录在会话 Cookie 名称中。因此，经过身份验证的用户可以在无需在安全 URL 中包含 google 或 github 路径值的情况下访问安全应用程序区域。

If the endpoint is running on http://localhost:8080, you can also provide UI options for users to log in to either http://localhost:8080/google or http://localhost:8080/github, without having to add specific /google or /github JAX-RS resource paths. Tenant identifiers are also recorded in the session cookie names after the authentication is completed. Therefore, authenticated users can access the secured application area without requiring either the google or github path values to be included in the secured URL.

默认解析还可以用于 Bearer 令牌身份验证。但实用性可能较差，因为租户标识符始终必须设置为最后路径段值。

Default resolution can also work for Bearer token authentication. Still, it might be less practical because a tenant identifier must always be set as the last path segment value.

Resolve tenants with a token issuer claim

支持 Bearer 令牌身份验证的 OIDC 租户可以使用访问令牌的颁发者进行解析。颁发者为基础的解析能够工作，必须满足以下条件：

OIDC tenants which support Bearer token authentication can be resolved using the access token’s issuer. The following conditions must be met for the issuer-based resolution to work:

  • The access token must be in the JWT format and contain an issuer (iss) token claim.

  • Only OIDC tenants with the application type service or hybrid are considered. These tenants must have a token issuer discovered or configured.

颁发者为基础的解析使用 quarkus.oidc.resolve-tenants-with-issuer 属性启用。例如：

The issuer-based resolution is enabled with the quarkus.oidc.resolve-tenants-with-issuer property. For example:

quarkus.oidc.resolve-tenants-with-issuer=true 1

quarkus.oidc.tenant-a.auth-server-url=${tenant-a-oidc-provider} 2
quarkus.oidc.tenant-a.client-id=${tenant-a-client-id}
quarkus.oidc.tenant-a.credentials.secret=${tenant-a-client-secret}

quarkus.oidc.tenant-b.auth-server-url=${tenant-b-oidc-provider} 3
quarkus.oidc.tenant-b.discover-enabled=false
quarkus.oidc.tenant-b.token.issuer=${tenant-b-oidc-provider}/issuer
quarkus.oidc.tenant-b.jwks-path=/jwks
quarkus.oidc.tenant-b.token-path=/tokens
quarkus.oidc.tenant-b.client-id=${tenant-b-client-id}
quarkus.oidc.tenant-b.credentials.secret=${tenant-b-client-secret}
1 Tenants tenant-a and tenant-b are resolved using a JWT access token’s issuer iss claim value.
2 Tenant tenant-a discovers the issuer from the OIDC provider’s well-known configuration endpoint.
3 Tenant tenant-b configures the issuer because its OIDC provider does not support the discovery.

Tenant resolution for OIDC web-app applications

对于 OIDC web-app 应用程序，租户解析必须在授权代码流期间执行至少 3 次，此时 OIDC 特定的租户配置将影响如何运行以下每个步骤。

Tenant resolution for the OIDC web-app applications must be done at least 3 times during an authorization code flow, when the OIDC tenant-specific configuration affects how each of the following steps is run.

Step 1: Unauthenticated user accesses an endpoint and is redirected to OIDC provider

当未经身份验证的用户访问安全路径时，用户将被重定向至 OIDC 提供者进行身份验证，并且将租户配置用于构建重定向 URI。

When an unauthenticated user accesses a secured path, the user is redirected to the OIDC provider to authenticate and the tenant configuration is used to build the redirect URI.

Static tenant configuration resolution 和 Dynamic tenant configuration resolution 部分中列出的所有静态和动态租户解析选项均可用于解析租户。

All the static and dynamic tenant resolution options listed in the Static tenant configuration resolution and Dynamic tenant configuration resolution sections can be used to resolve a tenant.

Step 2: The user is redirected back to the endpoint

在进行提供者身份验证后，用户会被重定向回 Quarkus 端点，并且将使用租户配置完成授权代码流。

After the provider authentication, the user is redirected back to the Quarkus endpoint and the tenant configuration is used to complete the authorization code flow.

Static tenant configuration resolution 和 Dynamic tenant configuration resolution 部分中列出的所有静态和动态租户解析选项均可用于解析租户。在开始租户解析之前，将使用授权代码流 state cookie 设置已解析的租户配置 ID 作为 RoutingContext tenant-id 属性：自定义动态 TenantConfigResolver 和静态 TenantResolver 租户解析器均可检查它。

All the static and dynamic tenant resolution options listed in the Static tenant configuration resolution and Dynamic tenant configuration resolution sections can be used to resolve a tenant. Before the tenant resolution begins, the authorization code flow state cookie is used to set the already resolved tenant configuration id as a RoutingContext tenant-id attribute: both custom dynamic TenantConfigResolver and static TenantResolver tenant resolvers can check it.

Step 3: Authenticated user accesses the secured path using the session cookie: the tenant configuration determines how the session cookie is verified and refreshed. Before the tenant resolution begins, the authorization code flow session cookie is used to set the already resolved tenant configuration id as a RoutingContext tenant-id attribute: both custom dynamic TenantConfigResolver and static TenantResolver tenant resolvers can check it.

例如，以下是自定义 TenantConfigResolver 如何避免创建已解析的租户配置，否则可能需要阻止对数据库或其他远程源的读取：

For example, here is how a custom TenantConfigResolver can avoid creating the already resolved tenant configuration, that may otherwise require blocking reads from the database or other remote sources:

package io.quarkus.it.keycloak;

import jakarta.enterprise.context.ApplicationScoped;
import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.OidcTenantConfig.ApplicationType;
import io.quarkus.oidc.TenantConfigResolver;
import io.quarkus.oidc.runtime.OidcUtils;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantConfigResolver implements TenantConfigResolver {

    @Override
    public Uni<OidcTenantConfig> resolve(RoutingContext context, OidcRequestContext<OidcTenantConfig> requestContext) {
        String resolvedTenantId = context.get(OidcUtils.TENANT_ID_ATTRIBUTE);
        if (resolvedTenantId != null) { 1
            return null;
        }

        String path = context.request().path(); 2
        if (path.endsWith("tenant-a")) {
            return Uni.createFromItem(createTenantConfig("tenant-a", "client-a", "secret-a"));
        } else if (path.endsWith("tenant-b")) {
            return Uni.createFromItem(createTenantConfig("tenant-b", "client-b", "secret-b"));
        }

        // Default tenant id
        return null;
    }

    private OidcTenantConfig createTenantConfig(String tenantId, String clientId, String secret) {
        final OidcTenantConfig config = new OidcTenantConfig();
        config.setTenantId(tenantId);
        config.setAuthServerUrl("http://localhost:8180/realms/"  + tenantId);
        config.setClientId(clientId);
        config.getCredentials().setSecret(secret);
        config.setApplicationType(ApplicationType.WEB_APP);
        return config;
    }
}
1 Let Quarkus use the already resolved tenant configuration if it has been resolved earlier.
2 Check the request path to create tenant configurations.

默认配置可能如下所示：

The default configuration may look like this:

quarkus.oidc.auth-server-url=http://localhost:8180/realms/default
quarkus.oidc.client-id=client-default
quarkus.oidc.credentials.secret=secret-default
quarkus.oidc.application-type=web-app

前述示例假定 tenant-a、tenant-b 和默认租户都会用于保护相同的端点路径。换句话说，用户使用 tenant-a 配置认证后，此用户在注销并清除或过期会话 Cookie 之前将无法选择使用 tenant-b 或默认配置进行认证。

The preceeding example assumes that the tenant-a, tenant-b and default tenants are all used to protect the same endpoint paths. In other words, after the user has authenticated with the tenant-a configuration, this user will not be able to choose to authenticate with the tenant-b or default configuration before this user logs out and has a session cookie cleared or expired.

多个 OIDC web-app 租户保护特定租户路径的情况较为少见，且还要求格外小心。当多个 OIDC web-app 租户（如 tenant-a、tenant-b 和默认租户）用于控制对特定租户路径的访问后，使用一个 OIDC 提供程序认证的用户不能访问要求使用另一个提供程序认证的路径，否则结果将不可预测，最有可能导致意外的认证失败。例如，如果 tenant-a 认证需要 Keycloak 认证，而 tenant-b 认证需要 Auth0 认证，那么，如果 tenant-a 认证的用户尝试访问受 tenant-b 配置保护的路径，则不会验证会话 Cookie，因为 Auth0 公共验证密钥不能用于验证 Keycloak 签名的令牌。避免多个 web-app 租户互相冲突的一种简单且建议的方式是设置特定租户会话路径，如以下示例所示：

The situtaion where multiple OIDC web-app tenants protect the tenant-specific paths is less typical and also requires an extra care. When multiple OIDC web-app tenants such as tenant-a, tenant-b and default tenants are used to control access to the tenant specific paths, the users authenticated with one OIDC provider must not be able to access the paths requiring an authentication with another provider, otherwise the results can be unpredictable, most likely causing unexpected authentication failures. For example, if the tenant-a authentication requires a Keycloak authentication and the tenant-b authentication requires an Auth0 authentication, then, if the tenant-a authenticated user attempts to access a path secured by the tenant-b configuration, then the session cookie will not be verified, since the Auth0 public verification keys can not be used to verify the tokens signed by Keycloak. An easy, recommended way to avoid multiple web-app tenants conflicting with each other is to set the tenant specific session path as shown in the following example:

package io.quarkus.it.keycloak;

import jakarta.enterprise.context.ApplicationScoped;
import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.OidcTenantConfig.ApplicationType;
import io.quarkus.oidc.TenantConfigResolver;
import io.quarkus.oidc.runtime.OidcUtils;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantConfigResolver implements TenantConfigResolver {

    @Override
    public Uni<OidcTenantConfig> resolve(RoutingContext context, OidcRequestContext<OidcTenantConfig> requestContext) {
        String resolvedTenantId = context.get(OidcUtils.TENANT_ID_ATTRIBUTE);
        if (resolvedTenantId != null) { 1
            return null;
        }

        String path = context.request().path(); 2
        if (path.endsWith("tenant-a")) {
            return Uni.createFromItem(createTenantConfig("tenant-a", "/tenant-a", "client-a", "secret-a"));
        } else if (path.endsWith("tenant-b")) {
            return Uni.createFromItem(createTenantConfig("tenant-b", "/tenant-b", "client-b", "secret-b"));
        }

        // Default tenant id
        return null;
    }

    private OidcTenantConfig createTenantConfig(String tenantId, String cookiePath, String clientId, String secret) {
        final OidcTenantConfig config = new OidcTenantConfig();
        config.setTenantId(tenantId);
        config.setAuthServerUrl("http://localhost:8180/realms/"  + tenantId);
        config.setClientId(clientId);
        config.getCredentials().setSecret(secret);
        config.setApplicationType(ApplicationType.WEB_APP);
        config.getAuthentication().setCookiePath(cookiePath); 3
        return config;
    }
}
1 Let Quarkus use the already resolved tenant configuration if it has been resolved earlier.
2 Check the request path to create tenant configurations.
3 Set the tenant-specific cookie paths which makes sure the session cookie is only visible to the tenant which created it.

应该如下调整默认租户配置：

The default tenant configuration should be adjusted like this:

quarkus.oidc.auth-server-url=http://localhost:8180/realms/default
quarkus.oidc.client-id=client-default
quarkus.oidc.credentials.secret=secret-default
quarkus.oidc.authentication.cookie-path=/default
quarkus.oidc.application-type=web-app

当多个 OIDC web-app 租户保护特定租户路径时，不建议采用相同的会话 Cookie 路径，应该避免这样做，因为它要求自定义解析器更加小心，例如：

Having the same session cookie path when multiple OIDC web-app tenants protect the tenant-specific paths is not recommended and should be avoided as it requires even more care from the custom resolvers, for example:

package io.quarkus.it.keycloak;

import jakarta.enterprise.context.ApplicationScoped;
import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.OidcTenantConfig.ApplicationType;
import io.quarkus.oidc.TenantConfigResolver;
import io.quarkus.oidc.runtime.OidcUtils;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomTenantConfigResolver implements TenantConfigResolver {

    @Override
    public Uni<OidcTenantConfig> resolve(RoutingContext context, OidcRequestContext<OidcTenantConfig> requestContext) {

        String path = context.request().path(); 1
        if (path.endsWith("tenant-a")) {
            String resolvedTenantId = context.get(OidcUtils.TENANT_ID_ATTRIBUTE);
	    if (resolvedTenantId != null) {
	        if ("tenant-a".equals(resolvedTenantId)) { 2
	            return null;
	        } else {
	           // Require a "tenant-a" authentication
                   context.remove(OidcUtils.TENANT_ID_ATTRIBUTE); 3
	        }
            }
            return Uni.createFromItem(createTenantConfig("tenant-a", "client-a", "secret-a"));
        } else if (path.endsWith("tenant-b")) {
            String resolvedTenantId = context.get(OidcUtils.TENANT_ID_ATTRIBUTE);
	    if (resolvedTenantId != null) {
	        if ("tenant-b".equals(resolvedTenantId)) { 2
	            return null;
	        } else {
	            // Require a "tenant-b" authentication
                   context.remove(OidcUtils.TENANT_ID_ATTRIBUTE); 3
	        }
            }
            return Uni.createFromItem(createTenantConfig("tenant-b", "client-b", "secret-b"));
        }

        // Set default tenant id
        context.put(OidcUtils.TENANT_ID_ATTRIBUTE, OidcUtils.DEFAULT_TENANT_ID); 4
        return null;
    }

    private OidcTenantConfig createTenantConfig(String tenantId, String clientId, String secret) {
        final OidcTenantConfig config = new OidcTenantConfig();
        config.setTenantId(tenantId);
        config.setAuthServerUrl("http://localhost:8180/realms/"  + tenantId);
        config.setClientId(clientId);
        config.getCredentials().setSecret(secret);
        config.setApplicationType(ApplicationType.WEB_APP);
        return config;
    }
}
1 Check the request path to create tenant configurations.
2 Let Quarkus use the already resolved tenant configuration if the already resolved tenant is expected for the current path.
3 Remove the tenant-id attribute if the already resolved tenant configuration is not expected for the current path.
4 Use the default tenant for all other paths. It is equivalent to removing the tenant-id attribute.

Disabling tenant configurations

自定义 TenantResolver 和 TenantConfigResolver 实现可能会在无法从当前请求推断出租户、且需要回退到默认租户配置时返回 null。

Custom TenantResolver and TenantConfigResolver implementations might return null if no tenant can be inferred from the current request and a fallback to the default tenant configuration is required.

如果您希望自定义解析器始终解决租户，则不需要配置默认租户解决。

If you expect the custom resolvers always to resolve a tenant, you do not need to configure the default tenant resolution.

  • To turn off the default tenant configuration, set quarkus.oidc.tenant-enabled=false.

当 quarkus.oidc.auth-server-url 未配置、但有自定义租户配置可用或已注册 TenantConfigResolver，默认租户配置会自动禁用。

The default tenant configuration is automatically disabled when quarkus.oidc.auth-server-url is not configured, but either custom tenant configurations are available or TenantConfigResolver is registered.

请注意，特定租户配置也可以禁用，例如：quarkus.oidc.tenant-a.tenant-enabled=false。

Be aware that tenant-specific configurations can also be disabled, for example: quarkus.oidc.tenant-a.tenant-enabled=false.

References