From 515e7737c73d923cf815ec84395cc372d26f1e0b Mon Sep 17 00:00:00 2001 From: Rolfe Dlugy-Hegwer Date: Mon, 23 Sep 2024 11:40:42 -0400 Subject: [PATCH] Update step headings to prevent confusing numbering (cherry picked from commit 8492f46394ce9b113cbd049f70c21cb7df92e650) --- .../asciidoc/security-openid-connect-multitenancy.adoc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc index 69e7453e96989..02ccf45bee913 100644 --- a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc @@ -894,19 +894,21 @@ quarkus.oidc.tenant-b.credentials.secret=${tenant-b-client-secret} 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 +.Step 1: Unauthenticated user accesses an endpoint and is redirected to OIDC provider 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. All the static and dynamic tenant resolution options listed in the <> and <> sections can be used to resolve a tenant. -==== Step 2: The user is redirected back to the endpoint +.Step 2: The user is redirected back to the endpoint 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. All the static and dynamic tenant resolution options listed in the <> and <> 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. +.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. 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: