Closed segfault24 closed 1 month ago
/cc @pedroigor (oidc), @sberyozkin (oidc)
Thanks @segfault24, this one will require some refactoring and deprecation due to the fact TenantResolver
which deals with the issuer based matching returns String
but it will have to return Uni<String>
to allow the just in time resolution, thus impacting a lot of code around it. It may take a bit of time...
This issue is indeed specific to the issuer-based tenant resolution strategy
Thanks @segfault24, this one will require some refactoring and deprecation due to the fact
TenantResolver
which deals with the issuer based matching returnsString
but it will have to returnUni<String>
to allow the just in time resolution, thus impacting a lot of code around it. It may take a bit of time...
yes, it does :-) it's chicken egg problem (determine tenant before you know the issuer of the tenant)
This issue is indeed specific to the issuer-based tenant resolution strategy
yep; I am getting closer to the fix and I am worried about retries. It can get to multitudes of retries on the tenants that might never become available. that would slow down application. I have been thinking to introduce simple interface that users can implement, like:
public interface TenantInitializationStrategy {
boolean tryToInitialize(String tenantId);
}
while default strategy would always return true; I am on the fence whether we should wait till someone ask for it.
I'll go without any strategy for now, because if user doesn't expect the tenant to get initialized, the user can disable the tenant.
Describe the bug
When using quarkus-oidc with named tenants and resolve-tenants-with-issuer, if an OIDC server is not available when the application starts, requests with credentials issued by that OIDC server will never succeed.
This behavior prevents an application from self-healing and requires a manual restart to return to normal operation.
Variations attempted:
Expected behavior
Quarkus eventually reattempts to contact the OIDC server, and subsequent requests succeed with 200 Ok.
Actual behavior
Quarkus never reattempts to contact the OIDC server, and all requests fail with 401 Unauthorized forever.
How to Reproduce?
https://github.com/segfault24/quarkus-oidc-bug/tree/main
Start the application, and wait for it to become ready. It will produce warnings about the OIDC server not being available.
In a second terminal, start the Keycloak container, and wait for it to become ready.
In a third terminal, acquire an access token and make a request to the application. It will always respond with 401 Unauthorized.
Output of
uname -a
orver
MINGW64_NT-10.0-22631 DESKTOP-REDACTED 3.4.10-87d57229.x86_64 2024-02-14 20:17 UTC x86_64 Msys
Output of
java -version
openjdk version "21.0.1" 2023-10-17 LTS OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS, mixed mode, sharing)
Quarkus version or git rev
3.13.1
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0) Maven home: C:\Users\austin.m2\wrapper\dists\apache-maven-3.9.7-bin\33482774\apache-maven-3.9.7 Java version: 21.0.1, vendor: Amazon.com Inc., runtime: C:\Program Files\Amazon Corretto\jdk21.0.1_12 Default locale: en_US, platform encoding: UTF-8 OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
Additional information
No response