AuthHandshakeMessageHandler: also try Basic auth when username is '<token>'.

[tmds]

OpenShift's image registry expects the '<token>' username to be handled using the Basic auth scheme.

Fixes #43319.

@baronfel ptal.

[baronfel]

I want to know more about how/why Docker/Podman work with OpenShift. From my reading of the Basic auth handler in regclient the Basic auth only uses username/password credentials, never Token-based credentials. The Token-based credentials are only used with Bearer auth.

Digging way down into how Docker does auth, I see everything relies on what's parsed from the WWW-authenticate header from the registry - can you see what's in the WWW-authenticate header when you ping your OpenShift registry?

[tmds]

@baronfel I tried to keep this PR focused on something backportable to .NET 9 so we can have working auth against the OpenShift registry.

I'm also interested in understanding better how docker/podman work so we can align on their behavior. I assume that may mean a bigger (and riskier) change.

I want to know more about how/why Docker/Podman work with OpenShift. From my reading of the Basic auth handler in regclient the Basic auth only uses username/password credentials, never Token-based credentials. The Token-based credentials are only used with Bearer auth.

Not sure if this matters, the auth is stored as:

{
	"auths": {
		"default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com": {
			"auth": "..."
		}
	}
}

And ... here is base64(username:password), and in this case username is the literal <token>.

can you see what's in the WWW-authenticate header when you ping your OpenShift registry?

It is:

www-authenticate: Bearer realm="https://default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com/openshift/token"

The full response is:

< HTTP/1.1 401 
< content-type: application/json
< docker-distribution-api-version: registry/2.0
< www-authenticate: Bearer realm="https://default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com/openshift/token"
< x-registry-supports-signatures: 1
< content-length: 87
< date: Wed, 11 Sep 2024 17:14:00 GMT
< set-cookie: 34727b82525eb26a530629c5bf0ec2f2=0e38c0640afce7f2163862707f60209e; path=/; HttpOnly; Secure; SameSite=None
< 
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

[baronfel]

That WWW-Authenticate is literally asking us to use the Bearer scheme though. I'm very confused by this.

[tmds]

That WWW-Authenticate is literally asking us to use the Bearer scheme though. I'm very confused by this.

Me too. I'm going to try and figure out what podman does exactly.

[tmds]

I'm going to try and figure out what podman does exactly.

Here it is:

When the server responds with WWW-Authenticate: Bearer, the client is here: https://github.com/containers/image/blob/31d4ad14fe4da8ef3969ff67297831ab291c76f1/docker/docker_client.go#L744-L748

And in the getBearerToken branch, it responds with Authorization: Basic: https://github.com/containers/image/blob/31d4ad14fe4da8ef3969ff67297831ab291c76f1/docker/docker_client.go#L842.

I tried both podman and docker with the config mentioned in #43354 (comment) and both are responding with Basic.

Currently the PR adds the Basic auth as a fall back on the existing logic.
I assume this is desired for requesting a .NET 9 backport.

To align further with podman/docker we need to update the existing auth code (and try additional cases).

[tmds]

To align further with podman/docker we need to update the existing auth code (and try additional cases).

I'll take a closer look at this and make a separate PR so we know what those changes would be. I hope to find some time for it next week or the week after.

[tmds]

I'll take a closer look at this and make a separate PR so we know what those changes would be.

WIP: #43491

[tmds]

Closing in favor of #43491.