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@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

On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen <sthorger@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@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

On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen <sthorger@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@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/

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

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev