harbor: 404 Error when using Azure as OIDC Provider

Issue

When configuring Authentication to use OIDC as the “Auth Mode” and using Azure as the Provider, the UI is giving the error “failed to verify connection” and the logs give:

2020-07-20T14:55:14Z [DEBUG] [/server/middleware/log/log.go:30]: attach request id 109256439487f6cc1afcd0337b4e7189 to the logger for the request POST /api/v2.0/system/oidc/ping
2020-07-20T14:55:14Z [DEBUG] [/server/middleware/security/session.go:47][requestID="109256439487f6cc1afcd0337b4e7189"]: a session security context generated for request POST /api/v2.0/system/oidc/ping
2020-07-20T14:55:14Z [ERROR] [/core/api/oidc.go:53]: Failed to verify connection: {URL:https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize VerifyCert:true}, err: 404 Not Found: 
2020-07-20T14:55:14Z [DEBUG] [/server/error/error.go:58]: {"errors":[{"code":"BAD_REQUEST","message":"failed to verify connection"}]}
2020/07/20 14:55:14.726 [D] [transaction.go:62]  | 10.225.172.130| 400 |   17.08772ms|   match| POST     /api/v2.0/system/oidc/ping   r:/api/v2.0/system/oidc/ping
2020-07-20T14:55:21Z [DEBUG] [/server/middleware/log/log.go:30]: attach request id 2a756a5f-5068-4413-a9a4-c0ab1fe55b0e to the logger for the request GET /api/v2.0/ping
2020-07-20T14:55:21Z [DEBUG] [/server/middleware/security/unauthorized.go:29][requestID="2a756a5f-5068-4413-a9a4-c0ab1fe55b0e"]: an unauthorized security context generated for request GET /api/v2.0/ping
2020/07/20 14:55:21.135 [D] [transaction.go:62]  | 10.225.172.193| 200 |    211.005µs|   match| GET      /api/v2.0/ping   r:/api/v2.0/ping
2020-07-20T14:55:22Z [DEBUG] [/server/middleware/log/log.go:30]: attach request id 92b4227b-aff9-4b67-9008-f7cfc3360a09 to the logger for the request GET /api/v2.0/ping
2020-07-20T14:55:22Z [DEBUG] [/server/middleware/security/unauthorized.go:29][requestID="92b4227b-aff9-4b67-9008-f7cfc3360a09"]: an unauthorized security context generated for request GET /api/v2.0/ping

OIDC Configuration:

Auth Mode: OIDC OIDC Provider Name: Azure OIDC Endpoint: https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize OIDC Client ID: <azure_appreg_client_id> OIDC Client Secret: <azure_appreg_client_secret> Group Claim Name: blank OIDC Scope: openid,offline_access,email Verify Certificate: checked

Azure App Registration Configuration:

Redirect URI: https://harbor.my.fqdn.com/c/oidc/callback Implicit grant: ID tokens checked Supported account types: Accounts in this organizational directory only API Permissions:

Microsoft.Graph.User.Read (Delegated)
Microsoft.Graph.User.Read.All (Delegated)
Microsoft.Graph.User.Read.All (Application)

Followed Docs: Azure AD OIDC Protocol here Consent Scopes here Configure App Registration here & here

Environment

Kubernetes: v1.17.7 Harbor: v2.0.1 OIDC Provider: Azure Deployment: Helm Chart v1.4.1

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (4 by maintainers)

Most upvoted comments

UPDATE: just stumbled upon this issue.

I tried all the “Endpoints” in Azure Portal -> Azure AD -> App Registrations -> Endpoints, including https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration. The working endpoint however is https://login.microsoftonline.com/{tentant_id}/v2.0 (w/o the trailing slash).

IMO, https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration should be the proper endpoint and would allow Harbor to grab important configuration details about the OIDC Provider.

fl-max on Jul 20, 2020

I’ll keep this open if there are more users hitting the same issue we may consider make this improvement.

reasonerjt on Sep 16, 2020

I see. So the code is doing something like "https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration" + "/.well-known/openid-configuration"?

Wouldn’t it make sense to just allow the full URI as a valid input? Maybe check if the suffix /.well-known/openid-configuration exists in the given endpoint and if not, add it?

fl-max on Jul 22, 2020

The /.well-known/openid-configuration context-path (Discovery Endpoint) appears to be the standard and is part of the RFC (see here and here).

When looking at other OIDC providers’ docs, they give this URI as well (ie. Auth0, Swagger).

This Discovery Endpoint returns important information regarding the interaction of OIDC Provider and could help automate some of the fields needed to configure it (ie. scopes_supported, claims_supported) or at the least help validate user provided configuration and subsequently provide rich error messages.

fl-max on Jul 21, 2020