Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Micronaut-security does not retry to retrieve openid-configuration from Keycloak if server is not found at startup #1797

Open
amorando10 opened this issue Sep 11, 2024 · 0 comments
Labels
type: enhancement New feature or request

Comments

@amorando10
Copy link

Expected Behavior

I use Micronaut version 4.3.8 and use Micronaut-security to connect to a keycloak server (oidc).

Behaviour when Keycloak is not accessible on application startup

The Keycloak realm in my test environment has a few users.
When all is well and a user tries to access my Micronaut application's UI, micronaut security will, as expected, redirect the user to the Keycloak UI to perform a login. This all works well.

However I have noticed that if on startup the micronaut application finds that my Keycloak server is not reachable then it will throw io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused.
If I then try to do a user authentication I get:

"message": "Internal Server Error: Bean of type io.micronaut.security.oauth2.client.DefaultOpenIdProviderMetadata with name quailfier myclient is disabled. Failed to retrieve OpenID configuration for myclient"

Which is expected as the Keycloak server is not reachable at this point.

Expected behaviour when Keycloak connectivity is restored

Expected behaviour when the Keycloak connection is restored.
If the issue that prevented the application from reaching the Keycloak server is resolved I would expect micronaut-security to retry the connection at the very least when the next login request is performed.

Actual Behaviour

However when connectivity with the Keycloak server is restored Micronaut-security never seems to retry to retrieve the configuration from Keycloak. If I try to login again I still get the same failure I got when Keycloak was not available. This persists until I restart the Micronaut application.

"message": "Internal Server Error: Bean of type io.micronaut.security.oauth2.client.DefaultOpenIdProviderMetadata with name quailfier myclient is disabled. Failed to retrieve OpenID configuration for myclient"

This seems quite bad as the application cannot recover at all if a keycloak connection issue happens at startup.

Steps To Reproduce

  1. Set up a micronaut application with Micronaut security to access a Keycloak server via oidc. The Keycloak server will be configured with a realm, a client and a few users.
  2. The Micronaut application will have a UI (I have used Thymeleaf views). The UI should access Views annotated with @Secured( {SecurityRule.IS_AUTHENTICATED}). This should force micronaut-security to redirect to the Keycloak login page to enable the realm user to log in and be authenticated
  3. Test that you can login and access the UI when Keycloak is available on Application startup.
  4. Stop keycloak and restart the micronaut application
  5. try to access the UI. you should get an error saying that the client is disabled + Failed to retrieve OpenID configuration for <client name>
  6. Now start Keycloak and wait for it to spin up - DO NOT restart your application
  7. Try again to access the application's UI. You will still get an error saying that the client is disabled + Failed to retrieve OpenID configuration for <client name> even though Keycloak is now available.

Expected behaviour is that at step 7 you should be able to login and authenticate with Keycloak

Environment Information

Ubuntu 23.04
Jdk 17

Example Application

No response

Version

4.3.8

@sdelamo sdelamo added the type: enhancement New feature or request label Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

2 participants