Configuring AzureAD authentication for Red Hat Quay

Solution Verified - Updated

Environment

  • Red Hat Quay
    • 3.x

Issue

  • How can one configure Azure AD for Quay Authentication?
  • What token endpoint to use for OIDC_SERVER field?

Resolution

Adding an OIDC provider to Quay is always the same, regardless of the identity provider being added. There are two ways to do it:

1. Use the config editor. Steps to follow are given below:

  • Under "External authentication" check "Add OIDC provider" button. Instructions should be straightforward from there on. Note that the OIDC server must end with a slash /.

  • Once provider is added, Quay will list three callback URLs that needs to be registered on the Azure side. These addresses will allow Azure to redirect back to Quay once authentication is confirmed.

2. Create the configuration directly in Quay config yaml. Following is an example of Azure AD Identity Provider:

AZURE_LOGIN_CONFIG:
    CLIENT_ID: 60e7f...
    CLIENT_SECRET: s2b8Q...
    OIDC_SERVER: https://sts.windows.net/6c878.../
    SERVICE_NAME: Azure AD
    VERIFIED_EMAIL_CLAIM_NAME: email

Above configuration will create the following redirect URIs with a particular format:

https://QUAY_HOSTNAME/oauth2/name_of_service/callback
https://QUAY_HOSTNAME/oauth2/name_of_service/callback/attach
https://QUAY_HOSTNAME/oauth2/name_of_service/callback/cli

Note:

  • Always use https://sts.windows.net/{tenant-id}/ endpoint for OIDC server
  • If one has firewall/proxy in use, make sure to whitelist all Azure provided list of API endpoints for each Oauth application that is created. Else one will face x509: certificate signed by unknown authority errors.

Root Cause

  • If one uses the default endpoint URL https://login.microsoftonline.com for OIDC_SERVER field, following error occurs:
Could not create provider for AzureAD. Error: oidc: issuer did not match the issuer returned by provider, expected "https://login.microsoftonline.com/73f2e714-xxxx-xxxx-xxxx-dffe1df8a5d5" got "https://sts.windows.net/73f2e714-xxxx-xxxx-xxxx-dffe1df8a5d5/"
  • OIDC_SERVER field reads the issuer from the OIDC config, falling back to the configured OIDC server. Its natural to assume the issuer for default URL to be https://login.microsoftonline.com. But its not. Azure AD token uses the sts.windows.net as the issuer identifier.

Diagnostic Steps

The shared capabilities of Azure AD enterprise tenants can be used to acquire access tokens to authenticate third party applications(here Quay). This is done via token endpoints provided by Azure AD. Auth requests from your Azure AD are federated to https://login.microsoftonline.com. The user's credentials are evaluated at https://login.microsoftonline.com and upon successful authentication, the user is directed back to https://login.windows.net which finally issues Quay app the token it requested

1. Check Quay debug logs to verify if the configurations were set correctly. The following entry shows a successful setup of Azure AD for authentication:

gunicorn-web stdout | 2023-01-20 15:41:52,071 [205] [DEBUG] [app] Starting request: urn:request:0d88de25-03b0-4cf9-b8bc-87f1ac099429 (/oauth2/azure/callback) {'X-Forwarded-For': '174.91.xx.xx'}
gunicorn-web stdout | 2023-01-20 15:41:52,074 [205] [DEBUG] [urllib3.connectionpool] Starting new HTTPS connection (1): login.windows.net:443
...
gunicorn-web stdout | 2023-01-20 15:41:52,603 [205] [DEBUG] [urllib3.connectionpool] https://login.windows.net:443 "POST /6c87869d-c91d-4797-9abd-dddf5ccdf89e/oauth2/token HTTP/1.1" 200 4585
gunicorn-web stdout | 2023-01-20 15:41:52,604 [205] [DEBUG] [oauth.oidc] Using key `...`, attempting to decode token `eyJ0eXAi...Q` with aud `c910c4...` and issuer `https://sts.windows.net/6c878.../`
...
gunicorn-web stdout | 2023-01-20 15:41:52,929 [205] [DEBUG] [urllib3.connectionpool] https://login.windows.net:443 "GET /common/discovery/keys HTTP/1.1" 200 12002
gunicorn-web stdout | 2023-01-20 15:41:53,670 [205] [DEBUG] [urllib3.connectionpool] https://login.windows.net:443 "GET /6c87869d-c91d-4797-9abd-dddf5ccdf89e/openid/userinfo?alt=json HTTP/1.1" 200 575
gunicorn-web stdout | 2023-01-20 15:41:53,671 [205] [DEBUG] [oauth.oidc] Found e-mail address `user1234@...` for sub `PK7Zpg2Y...`
gunicorn-web stdout | 2023-01-20 15:41:53,685 [205] [DEBUG] [data.model.user] Email and username are unique!
...
gunicorn-web stdout | 2023-01-20 15:41:53,731 [205] [DEBUG] [endpoints.common] Successfully signed in as user live_com_user1234 with uuid 3e001259-1d68-4ca2-8a18-f5182e38dab8
...
nginx stdout | 174.91.xx.xx (-) - - [20/Jan/2023:15:41:53 +0000] "GET /oauth2/azure/callback?code=0.ATAAnYaHbB3J... HTTP/2.0" 302 277 "https://QUAY_HOSTNAME/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0" (1.665 1889 1.664)

2. The below log entries indicate a problem with the setup:

Could not create provider for AzureAD. Error: oidc: issuer did not match the issuer returned by provider, expected "https://login.microsoftonline.com/73f2e714-xxxx-xxxx-xxxx-dffe1df8a5d5" got "https://sts.windows.net/73f2e714-xxxx-xxxx-xxxx-dffe1df8a5d5/"

Could not create provider for AzureAD. Error: Get "https://sts.windows.net/73f2e714-xxxx-xxxx-xxxx-dffe1df8a5d5/.well-known/openid-configuration": x509: certificate signed by unknown authority

3. Check if the endpoint sts.windows.net is protected by a certificate that is valid:

$ openssl s_client -connect sts.windows.net:443 < /dev/null | head -10

...
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = graph.windows.net
verify return:1
...

This certificate should be automatically trusted.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.