[docs] Update Docker Registry links to new locations. (#24193)
Closes keycloak/keycloak#24179
This commit is contained in:
parent
a0f04fa2be
commit
e889d0f12c
3 changed files with 6 additions and 6 deletions
|
@ -5,7 +5,7 @@ NOTE: Docker authentication is disabled by default. To enable see the https://ww
|
|||
|
||||
This section describes how you can configure a Docker registry to use {project_name} as its authentication server.
|
||||
|
||||
For more information on how to set up and configure a Docker registry, see the link:https://docs.docker.com/registry/configuration/[Docker Registry Configuration Guide].
|
||||
For more information on how to set up and configure a Docker registry, see the link:https://distribution.github.io/distribution/about/configuration/[Docker Registry Configuration Guide].
|
||||
|
||||
|
||||
|
||||
|
@ -22,7 +22,7 @@ auth:
|
|||
issuer: http://localhost:8080{kc_realms_path}/master
|
||||
----
|
||||
|
||||
This output can then be copied into any existing registry config file. See the link:https://docs.docker.com/registry/configuration/[registry config file specification] for more information on how the file should be set up, or start with link:https://github.com/distribution/distribution/blob/main/cmd/registry/config-example.yml[a basic example].
|
||||
This output can then be copied into any existing registry config file. See the link:https://distribution.github.io/distribution/about/configuration/[registry config file specification] for more information on how the file should be set up, or start with link:https://github.com/distribution/distribution/blob/main/cmd/registry/config-example.yml[a basic example].
|
||||
|
||||
WARNING: Don't forget to configure the `rootcertbundle` field with the location of the {project_name} realm's public key. The auth configuration will not work without this argument.
|
||||
|
||||
|
|
|
@ -9,10 +9,10 @@
|
|||
Docker authentication is disabled by default. To enable docker authentication, see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}.
|
||||
====
|
||||
[role="_abstract"]
|
||||
link:https://docs.docker.com/registry/spec/auth/[Docker Registry V2 Authentication] is a protocol, similar to OIDC, that authenticates users against Docker registries. {project_name}'s implementation of this protocol lets Docker clients use a {project_name} authentication server authenticate against a registry. This protocol uses standard token and signature mechanisms but it does deviate from a true OIDC implementation. It deviates by using a very specific JSON format for requests and responses as well as mapping repository names and permissions to the OAuth scope mechanism.
|
||||
link:https://distribution.github.io/distribution/spec/auth/[Docker Registry V2 Authentication] is a protocol, similar to OIDC, that authenticates users against Docker registries. {project_name}'s implementation of this protocol lets Docker clients use a {project_name} authentication server authenticate against a registry. This protocol uses standard token and signature mechanisms but it does deviate from a true OIDC implementation. It deviates by using a very specific JSON format for requests and responses as well as mapping repository names and permissions to the OAuth scope mechanism.
|
||||
|
||||
==== Docker authentication flow
|
||||
The authentication flow is described in the link:https://docs.docker.com/registry/spec/auth/token/[Docker API documentation]. The following is a summary from the perspective of the {project_name} authentication server:
|
||||
The authentication flow is described in the link:https://distribution.github.io/distribution/spec/auth/token/[Docker API documentation]. The following is a summary from the perspective of the {project_name} authentication server:
|
||||
|
||||
* Perform a `docker login`.
|
||||
* The Docker client requests a resource from the Docker registry. If the resource is protected and no authentication token is in the request, the Docker registry server responds with a 401 HTTP message with some information on the permissions that are required and the location of the authorization server.
|
||||
|
|
|
@ -4,10 +4,10 @@
|
|||
|
||||
NOTE: Docker authentication is disabled by default. To enable see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}.
|
||||
|
||||
link:https://docs.docker.com/registry/spec/auth/[Docker Registry V2 Authentication] is an OIDC-Like protocol used to authenticate users against a Docker registry. {project_name}'s implementation of this protocol allows for a {project_name} authentication server to be used by a Docker client to authenticate against a registry. While this protocol uses fairly standard token and signature mechanisms, it has a few wrinkles that prevent it from being treated as a true OIDC implementation. The largest deviations include a very specific JSON format for requests and responses as well as the ability to understand how to map repository names and permissions to the OAuth scope mechanism.
|
||||
link:https://distribution.github.io/distribution/spec/auth/[Docker Registry V2 Authentication] is an OIDC-Like protocol used to authenticate users against a Docker registry. {project_name}'s implementation of this protocol allows for a {project_name} authentication server to be used by a Docker client to authenticate against a registry. While this protocol uses fairly standard token and signature mechanisms, it has a few wrinkles that prevent it from being treated as a true OIDC implementation. The largest deviations include a very specific JSON format for requests and responses as well as the ability to understand how to map repository names and permissions to the OAuth scope mechanism.
|
||||
|
||||
==== Docker Auth Flow
|
||||
The link:https://docs.docker.com/registry/spec/auth/token/[Docker API documentation] best describes and illustrates this process, however a brief summary will be given below from the perspective of the {project_name} authentication server.
|
||||
The link:https://distribution.github.io/distribution/spec/auth/token/[Docker API documentation] best describes and illustrates this process, however a brief summary will be given below from the perspective of the {project_name} authentication server.
|
||||
|
||||
NOTE: This flow assumes that a `docker login` command has already been performed
|
||||
|
||||
|
|
Loading…
Reference in a new issue