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.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.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
を使用して解決します。
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 が同じで、Vert.x の RoutingContext
から抽出する必要がある場合は、OIDC Tenant Resolver からのテナント ID を Hibernate ORM Tenant Resolver または MongoDB と Panache Mongo Database Resolver に RoutingContext
属性として渡すことができます。次に例を示します。
public class CustomTenantResolver implements TenantResolver { @Override public String resolve(RoutingContext context) { String tenantId = extractTenantId(context); context.put("tenantId", tenantId); return tenantId; } }