aacampbell opened a new issue, #2243: URL: https://github.com/apache/polaris/issues/2243
### Describe the bug When a realm is configured to use mixed authentication, it first tries to authenticate internally and, should that fail, will then try to authenticate against the configured external OIDC tenant. When that external tenant uses a self-generated RSA key to sign the token, Polaris' internal authentication system fails to verify the token's signature, which is expected. What is not expected is that the fallback to the external OIDC tenant does not then occur, but instead a 401 is returned to the user. If the fallback did occur, then the OIDC authenticator would successfully verify the token's signature and authorization might then be granted. While it might be expected that the external OIDC provider would sign the token using a key known to Polaris' internal auth system, this is not necessarily the case and should not be required. This issue was discovered by using Keycloak in an ephemeral docker-compose container, which is not an uncommon arrangement for learning and testing of integration of systems like Keycloak and Polaris. ### To Reproduce 1. Create a Keycloak instance that uses self-generated keys 2. Create a Polaris instance that is configured to use Mixed authentication with Keycloak as the external provider 3. Get a token from Keycloak 4. Use this token as the Bearer token when communicating with one of Polaris' REST interfaces ### Actual Behavior Polaris does not try external OIDC. ### Expected Behavior Polaris should fall back to trying the configured external OIDC. ### Additional context The same works as expected when using just External Authentication, suggesting that the issues lies with the handling of the signature verification failure. ### System information Polaris Catalog Version: 1.0.0-incubating (docker image) Keycloak version: 26.3.1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
