Troubleshooting DataHub OIDC Authentication Issues

ui
1

Original Slack Thread

<@U06TM7M40RK> I am testing DataHub authentication locally in a development environment using Keycloak as my OIDC provider. In Docker-Compose I added the required environment variables to enable OIDC and have configured Keycloak client-id, realm, credentials. What could cause “Failed to redirect to Sign Sign-On provider.”

2

The error “Failed to redirect to Single Sign-On provider” typically indicates a misconfiguration in the Single Sign-On (SSO) setup. Here are some common causes and troubleshooting steps based on the provided data sources:

  1. Verify Environment Variables: Ensure that all the required environment variables are correctly set in your docker-compose file. This includes AUTH_OIDC_CLIENT_ID, AUTH_OIDC_CLIENT_SECRET, AUTH_OIDC_DISCOVERY_URI, and AUTH_OIDC_BASE_URL. Double-check for any typos or missing values.

  2. Check Network Connectivity: Make sure that the datahub-frontend container can reach the Keycloak server. You can test this by running a curl command from within the datahub-frontend container to the AUTH_OIDC_DISCOVERY_URI (https://datahubproject.io/docs/authentication/guides/sso/configure-oidc-react|source).

  3. Review Logs: Check the logs of the datahub-frontend container for more detailed error messages. You can enable verbose logging by setting the AUTH_VERBOSE_LOGGING environment variable to true (https://datahubproject.io/docs/authentication/guides/sso/configure-oidc-react|source).

  4. Correct URLs: Ensure that the URLs in the SSO and OIDC configuration are correct and accessible. This includes the AUTH_OIDC_DISCOVERY_URI and AUTH_OIDC_BASE_URL. The AUTH_OIDC_BASE_URL should match the login redirect URL you’ve registered with your identity provider (https://github.com/datahub-project/datahub/blob/master/docs/authentication/guides/sso/configure-oidc-react.md|source).

  5. Restart Frontend: After making any changes to the configuration, restart the datahub-frontend container to apply the changes (https://datahubproject.io/docs/0.14.0/authentication/guides/sso/configure-oidc-react|source).

If these steps do not resolve the issue, it might be helpful to check the Keycloak configuration to ensure that the client ID, secret, and redirect URIs are correctly set up.

Would you like more detailed guidance on any specific step?

Sources:

3

<@U06TM7M40RK> Checking network connectivity from the datahub-frontend container, I am unable to curl the AUTH_OIDC_DISCOVERY_URI. From the host I can curl and open the AUTH_OIDC_DISCOVERY_URI so I know it is valid. Next step, I am looking into this connectivity issue in my Docker-Compose stacks.

4

<@U06TM7M40RK> From inside the datahub-frontend container I can ping IP address of Keycloak and by Docker service name. Still unable to curl AUTH_OIDC_DISCOVERY_URI from inside the datahub-frontend container.

5

<@U06TM7M40RK> Do I need to enable SSL in my local development stack to test DataHub OIDC authentication???

6

It seems likely that enabling SSL might be necessary for testing DataHub OIDC authentication, especially if your OIDC provider (Keycloak in this case) requires secure connections for the redirect URIs. Here are some considerations and steps you might take:

  1. SSL Requirement: Some OIDC providers require that redirect URIs use HTTPS. If Keycloak is configured to enforce this, you will need to set up SSL for your local DataHub instance.

  2. Local SSL Setup: You can set up SSL locally by using a self-signed certificate or a local development certificate. This involves configuring your docker-compose setup to use HTTPS for the datahub-frontend service.

  3. Proxy Configuration: Another approach is to use a reverse proxy like Nginx or Traefik in front of your DataHub services to handle SSL termination. This proxy can be configured to serve HTTPS traffic and forward it to your DataHub services over HTTP.

  4. Keycloak Configuration: Ensure that Keycloak is configured to accept the redirect URI with HTTPS. You might need to update the client settings in Keycloak to reflect the HTTPS redirect URI.

  5. Testing Locally: If you are testing locally and SSL is not strictly required by your OIDC provider, you might be able to use HTTP by configuring Keycloak to accept non-secure redirect URIs for development purposes.

For more detailed steps on setting up SSL in Docker, you might want to refer to resources on configuring SSL with Docker and your chosen reverse proxy.

Would you like more detailed guidance on setting up SSL for your local development environment?

Sources:

7

<@U06TM7M40RK> I resolved OIDC redirect issues. When I login via OIDC successfully I now see “Failed to sign in using Single Sign-On” notification. When I click on “Sign in with SSO” all is ok and I login to DataHub. What would be causing the failed sign in notification???

8

The “Failed to sign in using Single Sign-On” notification, despite a successful login upon retry, could be due to several factors related to the OIDC configuration or session management. Here are some potential causes and troubleshooting steps:

  1. Session Management Issues: The initial login attempt might be failing due to session management issues. Ensure that the session store is correctly configured to handle state parameters and session persistence. This might involve checking the PlayCacheSessionStore settings in your application.conf file (https://github.com/datahub-project/datahub/blob/master/docs/authentication/guides/sso/configure-oidc-react.md|source).

  2. State Parameter: The error could be related to the state parameter used in the OIDC authentication flow. This parameter is used to maintain state between the authentication request and the callback. If it is missing or incorrect, the authentication process might fail. Ensure that the state parameter is correctly handled in your configuration (https://github.com/datahub-project/datahub/issues/8369|source).

  3. Token Validation: There might be an issue with the ID token validation. Ensure that the token is signed and that your configuration matches the expected signing algorithm. Check the AUTH_OIDC_PREFERRED_JWS_ALGORITHM setting if applicable (https://github.com/datahub-project/datahub/issues/12420|source).

  4. Logs and Debugging: Check the logs of the datahub-frontend container for more detailed error messages. Enabling verbose logging by setting the AUTH_VERBOSE_LOGGING environment variable to true can provide more insights into what might be going wrong during the initial login attempt (https://github.com/datahub-project/datahub/issues/8965|source).

  5. Configuration Consistency: Double-check that all OIDC-related environment variables are consistently set and match the configuration in your identity provider. This includes AUTH_OIDC_CLIENT_ID, AUTH_OIDC_CLIENT_SECRET, AUTH_OIDC_DISCOVERY_URI, and AUTH_OIDC_BASE_URL.

If these steps do not resolve the issue, it might be helpful to review the specific error messages in the logs to pinpoint the exact cause of the failure.

Would you like more detailed guidance on any specific step?

Sources:

9

<@U06TM7M40RK> “Failed to sign in using Single Sign-On” notification only occurs in Chrome browser. In Firefox this behavior does not occur. Strange.

10

The issue where the “Failed to sign in using Single Sign-On” notification occurs only in Chrome but not in Firefox could be related to browser-specific settings or behaviors. Here are some potential causes and troubleshooting steps:

  1. Cookies and Cache: Chrome might have cached some old session data or cookies that are causing issues. Try clearing the cookies and cache in Chrome to see if that resolves the problem.

  2. SameSite Cookie Attribute: Chrome has stricter enforcement of the SameSite cookie attribute, which can affect how cookies are handled during cross-site requests. Ensure that your cookies are set with SameSite=None and Secure=true if you are using HTTPS (https://github.com/datahub-project/datahub/blob/master/docs/managed-datahub/chrome-extension.md|source).

  3. Extensions and Add-ons: Browser extensions in Chrome might interfere with the authentication process. Try disabling extensions to see if one of them is causing the issue.

  4. Incognito Mode: Test the login process in Chrome’s Incognito mode. This can help determine if the issue is related to cached data or extensions, as Incognito mode runs without extensions and uses a fresh session.

  5. Network and Security Settings: Check Chrome’s network and security settings to ensure that nothing is blocking or interfering with the authentication process.

  6. Console Errors: Open the Developer Tools in Chrome (F12 or right-click > Inspect) and check the Console tab for any errors or warnings that might provide more insight into what’s going wrong during the login process.

If these steps do not resolve the issue, it might be helpful to compare the network requests and responses in both browsers to identify any differences.

Would you like more detailed guidance on any specific step? :+1: 1 button :-1: 0 button :bulb: Hint: Mention <@U06TM7M40RK> in the thread for followups.