Relation of authentication and authorization to docker commands

From my understanding to complete a "docker push" the user must be logged in first, e.g. "docker login registry.external".

From the documentation at spec/auth/token.md it says:

Attempt to begin a push/pull operation with the registry.

1. If the registry requires authorization it will return a 401 Unauthorized HTTP response with information on how to authenticate.
2. The registry client makes a request to the authorization service for a signed JSON Web Token.
3. The authorization service returns a token.
4. The client retries the original request with the token embedded in the request header.
5. The Registry authorizes the client and begins the push/pull session as usual.

Is there an assumption before these steps start that the user is authenticated?

[stevvooe]

@jambroo Not sure if this helps but https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md should be read as a specification, rather than a how-to.

This assumes that the client is some registry client that requires a token for the registry. The relation to "docker pull" and "docker login" are not relevant to this documentation, other than that this flow may be a part of "docker login" or "docker push".

What are you trying to understand by asking this question?

@stevvooe Thanks for looking at this issue :)

I guess what I am trying to understand from reading this documentation is how authentication and authorization works. To push an image to a registry you need to login then push. I am trying to understand how to do authentication, in particular the security associated with it.

The reason I stumbled upon the token.md page was this guide https://github.com/docker/distribution/blob/master/docs/authentication.md#token-based-delegated-authentication.

At the end of the day what I am trying to see is user A logging into registry and pushing and image then user B logging into registry and not having access to user As image unless it is shared explicitly.

[stevvooe]

@jambroo The best way to understand the authentication system is probably to read the code. The Token Auth specification will give you some insight, but also the registry auth package, in addition to the main web application.

The system uses uses signed JWT that confer access based on a trusted signer. Effectively, the docker client asks the authentication server if it can do a specific operation on a repository. If the user has permission, the auth server issues a token signed by a certificate trusted by the registry (called a JWT). This token is then included in the http request to the registry. The registry verifies and authenticates the token. If the token is trusted, the operation is allowed to proceed.

This can be hard to understand at first, but, once it clicks, you'll wonder why you did it any other way. ;)

Does this information suffice? Do you have any further questions?

[kevinsimper]

@stevvooe I have the same problem, I don't understand they way docker login works together with this. There is not even a mention of docker login, and how else are you going to know the username, but who authenticate the username? How is it determine that you are jlhawn?

[stevvooe]

@kevinsimper @jambroo This doesn't have much to do with docker login, other than that the credentials used to authenticate with the token server or via basic auth come from docker login. Under regular usage, you don't need to know anything about this flow.

What specific problem are you trying to solve?

@stevvooe I think I understand now that the login is the authentication and done at the start and later on there is authorization

I think the problem can be explained by this guys post, which he seems to solve.
http://the.binbashtheory.com/creating-private-docker-registry-2-0-with-token-authentication-service/

Thanks for your help, @stevvooe

[stevvooe]

@jambroo Interesting post. Thank you for the pointer.

Let me know if you need anything else. I'll close this issue for now.