-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ACR authentication with token credentials is inconsistent (basic auth not accepted, but requested in 401 response) #466
Comments
The repository based token is supposed to be consumed through basic auth. Protocol wise it is same like admin user account. @maxwolffe, want to confirm the registry name is |
@yugangw-msft - Thanks for the response. GoogleContainerTools/jib#2784 has been resolved, they changed their auth flow to use bearer auth when the first response from Azure returned WWW-Authenticate: Bearer and authentication with tokens succeeded. The registry name is mwolffetestingmicroservices.azurecr.io. I could probably recreate this issue for you using Jib 2.5.0 or earlier if it'd be helpful. |
@maxwolffe, thanks for the information @shizhMSFT, on repo based token, how does it work with basic auth? On this error, it appears we treated the repo-token as the service principal name which obviously won't work. I am looking at registry activities from There is another issue happening earlier that through the bearer challenge, our token server issued the access token, but the subsequent request didn't use it for "Authorization" header, rather dropped it and went through the basic auth. This issue is not on us, and I guess that is what jib fixed. |
Looks like there's a bit of confusion, so allow me to clarify! Notice that Jib was interacting with two repositories: one for pulling and the other for pushing. Let's call them "base-repo" and "target-repo". Note that the "target-repo" is irrelevant of the failure in the auth flow we're talking about.
Another issue is that, as @maxwolffe mentioned, right after the basic auth failed on "base-repo", ACR illogically asks Jib to do basic auth again. |
@yugangw-msft The repository-scoped permissions (preview) feature is designed to be working only with bearer auth in the current stage. By default, ACR challenges for bearer auth with |
@shizhMSFT, thanks for the clarification! |
Closing as no follow up is required from ACR |
@yugangw-msft - is it not an issue that ACR is challenging with Basic auth (per @shizhMSFT's comment), but only accepts Bearer auth? Or is it the case that tokens will support basic auth in the future? |
Good question. CC @sajayantony for context why basic auth is not available with repo based permission token and whether we plan to add it in future. |
There are multiple fundamental issue with Basic Auth and for ACR it's more about cost vs benefit of supporting multiple authentication mechanism. So from a direction standpoint we can assume that Bearer would most likely be the only supported model. |
Hey all, first time ticket, love ACR in general, let me know if anything in here is unclear :)
Describe the bug
The tokens feature (in preview) seems to have inconsistent authentication semantics:
a. Token credentials provided in basic authentication fails but basic authentication is accepted with access key credentials.
b. Azure responds to failed authentication requests with an auth header
WWW-Authenticate: Basic
, but doesn't accept basic credentials (Bearer authentication is accepted. If basic auth is not supported for tokens, consider always responding with an allowed auth scheme.This was initially reported to the jib project - GoogleContainerTools/jib#2784. They're making changes, but suggested that I also report it here, since there appears to be some oddness in ACR's authentication flow.
More details an debugging in the "Additional Context" section below.
Expected behavior
ACR accepts basic authentication for tokens or provides
WWW-Authenticate: Bearer
(or whichever is the preferred authentication method) headers in 401 responses.Any relevant environment information
Additional context
In long:
I'm running an AzureDevOps Pipelines build agent which is pulling a custom base image from Azure Container Registry, building an image, and pushing to the same registry. I'm using jib, a container packaging tool to pull a base image from my private ACR repo and then push the built image to the same repo. I'm supplying credentials to jib using the <to/from> command lines, like so:
The to/from username and password are the same and are using a token which is configured to have both push and pull rights to all of my repositories (_repositories_admin has this property):
The pull authentication flow fails, because jib is first attempting basic authentication (ignoring the WWW-Authenticate: Bearer header - behavior they are changing), then is being instructed by Azure to attempt Basic authentication again (via the WWW-Authenticate header) which fails. This is the heart of the bug - Basic auth fails, but then basic auth is requested by ACR.
Bearer authentication does succeed (which is what jib is changing their flow to use)
debug log (click to expand)
However, if use an admin user access key, as below, the basic authentication succeeds.
debug log (click to expand)
The text was updated successfully, but these errors were encountered: