[keycloak-dev] Docker Protocol?

Bill Burke bburke at redhat.com
Wed Aug 17 08:56:00 EDT 2016


Can't you just have "enabled": false in keycloak-server.json for that 
provider?


On 8/17/16 3:41 AM, Stian Thorgersen wrote:
> We could have it included in KC, but disabled by default. Having the 
> ability to enable/disable features is something we need in either 
> case. Especially for product as we'd like to have certain community 
> only features (or tech preview features) disabled by default to make 
> it obvious to customers they are using unsupported features.
>
> We'd need to figure out some way to automate testing of it though. We 
> obviously can't manually test with Docker on a regular basis. Do you 
> have any plans around how to test it?
>
> On 16 August 2016 at 21:24, Josh Cain <josh.cain at redhat.com 
> <mailto:josh.cain at redhat.com>> wrote:
>
>     Couldn't agree more that Docker should use an
>     existing/standards-based auth protocol.  Problem is, we need our
>     Keycloak IDP to start talking to docker registries.  Since we have
>     a hard requirement to talk to docker registries, our IDP has to
>     speak docker auth.  There are already a number of Docker registry
>     authorization servers out there, so there seems to be a need out
>     there in the community as well.
>
>     We're going to develop one and push it out such that it's publicly
>     accessible in any case, I was just curious as to whether the dev
>     team would want to incorporate this into the product.
>
>
>     Josh Cain | Software Applications Engineer
>     /Identity and Access Management/
>     *Red Hat*
>     +1 256-452-0150 <tel:%2B1%20256-452-0150>
>
>     On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         I'm not sure we'd like to have a Docker registry specific
>         protocol added directly to Keycloak. Seems like Docker
>         registry should rather get their act together and comply with
>         existing protocols rather than invent their own.
>
>         We did have an idea of creating some repository for
>         extensions. These would be community maintained, not included
>         in product and wouldn't receive the same level of testing.
>         Maybe that would be a good place for this. With Bills recent
>         deployer work it could be easier to allow users to deploy
>         custom extensions as well.
>
>         On 15 August 2016 at 16:41, Josh Cain <josh.cain at redhat.com
>         <mailto:josh.cain at redhat.com>> wrote:
>
>             Hi Stian,
>
>             Docker's auth V2 (docs link above) is Oauth-ish, but
>             doesn't seem to conform 100% to the specification.  I
>             started by just trying to stand up an OIDC endpoint to
>             talk to docker and Keycloak threw a "Missing parameters:
>             response_type" error.  Turns out, Docker sends the GET
>             request like this:
>
>             /auth/realms/redhat-external/protocol/docker-v2/auth?account=jcain&scope=repository%3Acentos%3Apull&service=docker-registry
>
>             Not only is the request missing the request_typer
>             paremeter, but Docker uses different nomenclature than the
>             OAuth/OIDC standard.  For instance, I would expect the
>             'service' param to appear as the client_id param to
>             conform to the OAuth spec.
>
>             Since it uses different nomenclature, I thought it would
>             be a much cleaner implementation to just implement it as
>             its own protocol.  Didn't want to muddy up a clean
>             OIDC/OAuth implemention.
>
>             Are there workarounds to deal with these differences that
>             I'm missing?
>
>
>             Josh Cain | Software Applications Engineer
>             /Identity and Access Management/
>             *Red Hat*
>             +1 843-737-1735 <tel:%2B1%20843-737-1735>
>
>             On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen
>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>                 I'm not sure I fully understand. Are you using a
>                 Docker client to authenticate with Keycloak? That
>                 works with the standard OIDC flows, but it requires
>                 some additional claims in the token which you are
>                 adding with a protocol mapper?
>
>                 On 12 August 2016 at 15:31, Josh Cain
>                 <josh.cain at redhat.com <mailto:josh.cain at redhat.com>>
>                 wrote:
>
>                     Hi All,
>
>                     We want to use Keycloak as the IDP/Token issuer
>                     for authentication with a docker registry as per
>                     the specification found here:
>
>                     https://docs.docker.com/registry/spec/auth/
>                     <https://docs.docker.com/registry/spec/auth/>
>
>                     I've implemented a Protocol Mapper in Keycloak
>                     that successfully uses the IDP to perform a login
>                     against a registry/docker client.  Is this
>                     something that the team is interested in building
>                     into the product?  If so, I'd be happy to push
>                     back upstream.
>
>                     Josh Cain | Software Applications Engineer
>                     /Identity and Access Management/
>                     *Red Hat*
>                     +1 843-737-1735 <tel:%2B1%20843-737-1735>
>
>                     _______________________________________________
>                     keycloak-dev mailing list
>                     keycloak-dev at lists.jboss.org
>                     <mailto:keycloak-dev at lists.jboss.org>
>                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>                     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/16f0252e/attachment.html 


More information about the keycloak-dev mailing list