5.6. アプリケーションの設定

# Default tenant configuration
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=multi-tenant-client
quarkus.oidc.credentials.secret=secret
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

最初の設定は、リクエストからテナントを推測できない場合に使用する必要があるデフォルトのテナント設定です。Dev Services for Keycloak を使用したマルチテナントアプリケーションのテストをサポートするために、quarkus.oidc.auth-server-url で %prod プロファイル接頭辞が使用されることに注意してください。この設定では、Keycloak インスタンスを使用してユーザーを認証します。

TenantConfigResolver によって提供される 2 番目の設定は、受信リクエストが tenant-a テナントにマップされるときに使用されます。

両方の設定は、異なる realms を使用しながら、同じ Keycloak サーバーインスタンスにマップされます。

あるいは、application.properties でテナント tenant-a を直接設定することもできます。

# Default tenant configuration
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=multi-tenant-client
quarkus.oidc.credentials.secret=secret
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.credentials.secret=secret
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 を使用して解決します。

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 実装からテナントを解決するときに正しくマップするには、それぞれに一意のエイリアスがあることを確認します。

ただし、application.properties でテナントを設定し、TenantResolver を使用して解決する静的テナント解決を使用すると、リクエストが個々のテナントにどのようにマッピングされるかがわからず、テナント固有の quarkus.oidc.<tenant-id>.auth-server-url 値を動的に提供できないため、Dev Services for Keycloak を使用したエンドポイントのテストには機能しません。したがって、application.properties 内のテナント固有の URL で %prod 接頭辞を使用することは、テストモードと開発モードの両方で機能しません。

注記

現在のテナントが OIDC web-app アプリケーションを表す際、テナント固有の状態またはセッション Cookie がすでに存在する場合に、コード認証フローを完了するすべての要求とすでに認証された要求に対してカスタムテナントリゾルバーが呼び出されるまでに、現在の io.vertx.ext.web.RoutingContext には、tenant-id 属性が含まれます。したがって、複数の OIDC プロバイダーを使用する際、RoutingContext に tenant-id 属性が設定されていない場合にのみ、テナント ID を解決するためにパス固有のチェックが必要になります。次に例を示します。

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];
        }
    }
}

これは、カスタム TenantResolver が登録されていない場合に、Quarkus OIDC が静的カスタムテナントを解決する方法です。

同様の手法を TenantConfigResolver でも使用できます。コンテキストで提供される tenant-id は、以前のリクエストですでに準備されている OidcTenantConfig を返すことができます。

注記

Hibernate ORM マルチテナントまたは MongoDB と Panache マルチテナントも使用していて、両方のテナント ID が同じ場合は、tenant-id を使用して RoutingContext 属性からテナント ID を取得できます。詳細は、以下を参照してください。

5.6. アプリケーションの設定

詳細情報

試用、購入および販売

コミュニティー

会社概要

多様性を受け入れるオープンソースの強化

Red Hat ドキュメントについて

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links