5.10. 静的テナント設定の解決

次の application.properties の例は、TenantResolver メソッドを使用して、a および b という名前の 2 つのテナントのテナント ID を解決する方法を示しています。

# 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 を返すことができます。

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 ですが、必要に応じて、より複雑なテナント ID 解決ロジックを実装できます。

テナント識別子のデフォルトの解決は規則に基づいており、認証要求には要求パスの最後のセグメントにテナント識別子が含まれている必要があります。

次の application.properties の例は、google と github という名前の 2 つのテナントを設定する方法を示しています。

# 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 が現在のユーザーを認証すると、ユーザーは、JAX-RS エンドポイント上のセキュリティーで保護されたリソースパスなど、認証されたユーザーの /signed-in 領域に戻されます。

最後に、デフォルトのテナント解決を完了するには、次の設定プロパティーを設定します。

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

エンドポイントが http://localhost:8080 で実行している場合は、特定の /google または /github JAX-RS リソースパスを追加せずに、ユーザーが http://localhost:8080/google または http://localhost:8080/github にログインするための UI オプションを提供することもできます。認証が完了すると、テナント識別子もセッション Cookie 名に記録されます。したがって、認証されたユーザーは、セキュリティー保護された URL に google または github のパス値を含める必要なく、セキュリティー保護されたアプリケーション領域にアクセスできます。

デフォルトの解決は、ベアラートークン認証でも機能します。ただし、テナント識別子は常に最後のパスセグメント値として設定する必要があるため、あまり実用的ではない可能性があります。

io.quarkus.oidc.TenantResolver を使用する代わりに、io.quarkus.oidc.Tenant アノテーションを使用してテナント識別子を解決することができます。

アプリケーションが hr テナントと default テナントの 2 つの OIDC テナントをサポートしていると仮定すると、@Tenant("hr") を持つすべてのリソースメソッドとクラスは、quarkus.oidc.hr.auth-server-url によって設定された OIDC プロバイダーを使用して認証されます。対照的に、他のすべてのクラスとメソッドは、引き続きデフォルトの OIDC プロバイダーを使用して認証されます。

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!";
    }
}