404 Error when using Azure as OIDC Provider

[fl-max]

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

[fl-max]

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.

[reasonerjt]

Hi, this is opinionated, but this has been documented and we don't want to introduce such break change.
Maybe we add more information on the UI to better clarify

[fl-max]

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.

[reasonerjt]

Actually Harbor DOES rely on the discovery URI to get information.

The expected value of the OIDC ENDPOINT is the URI does not contain the suffix /.well-known/openid-configuration

[fl-max]

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?

[reasonerjt]

This may help, but I don't think most users will consider the well-known uri as OIDC endpoint and I think it's documented.

[reasonerjt]

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

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lindhe]

This may help, but I don't think most users will consider the well-known uri as OIDC endpoint and I think it's documented.

I cannot find it here. Is there anywhere else that it's expected to be documented?

[acobaugh]

Just hit this as well, and the logging is confusing because the value I provided for the endpoint definitely doesn't 404 for me. IMO this needs to be documented better. Since the UI doesn't have separate fields for each of the individual oidc endpoints, then I think most users are going to assume that the "OIDC endpoint" is the well-known uri.

021-07-21T14:38:39Z [ERROR] [/server/v2.0/handler/oidc.go:32]: Failed to verify connection: {URL:https://login.microsoftonline.com/xxxxx/v2.0/.well-known/openid-configuration VerifyCert:true}, err: 404 Not Found```

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lindhe]

I think this issue should not be closed until there's at least better documentation.

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.

[sziyan]

Chipping in to feedback that I encountered the same issue as well when using Azure AD as IDP.