From 7bad47ad9749d7acb1d1416dea7bbf6ea2f98639 Mon Sep 17 00:00:00 2001 From: Sergey Beryozkin Date: Thu, 4 Apr 2024 15:05:57 +0100 Subject: [PATCH] Fix the recent OIDC tenancy doc refactoring error --- .../security-openid-connect-multitenancy.adoc | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc index 51c2020d8a7e21..f6ca2959b8b375 100644 --- a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc @@ -594,10 +594,10 @@ Although `alice` exists in both tenants, the application treats them as distinct == Tenant resolution order 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. -4. Default OIDC tenant is selected if a tenant id has not been resolved after the preceeding steps. +* `io.quarkus.oidc.Tenant` annotation is checked first if the proactive authentication is disabled. +* Dynamic tenant resolution using a custom `TenantConfigResolver`. +* 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. +* Default OIDC tenant is selected if a tenant id has not been resolved after the preceeding steps. See the following sections for more information: @@ -656,24 +656,6 @@ 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. -[[configure-tenant-paths]] -=== Configure tenant paths - -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: - -[source,properties] ----- -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. - -TIP: Path-matching mechanism works exactly same as in the xref:security-authorize-web-endpoints-reference.adoc#authorization-using-configuration[Authorization using configuration]. - [[tenant-config-resolver]] == Dynamic tenant configuration resolution @@ -798,6 +780,24 @@ public class CustomTenantResolver implements TenantResolver { 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]] +=== Configure tenant paths + +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: + +[source,properties] +---- +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. + +TIP: Path-matching mechanism works exactly same as in the xref:security-authorize-web-endpoints-reference.adoc#authorization-using-configuration[Authorization using configuration]. + [[default-tenant-resolver]] === Default resolution