[keycloak-dev] Docker Protocol?

Tue Nov 29 01:17:21 EST 2016

On 21 November 2016 at 19:21, Josh Cain <jcain at redhat.com> wrote:

> Finally got some time to try to wrap this one up, but I had a few
> questions:
>
> - Was looking to add a new section to the server-administration-guide
> (7.4, under SSO Protocols), but am not sure how to do that using
> GitBooks.  I can make comments, but am unsure how a new page would be
> added in a PR-style flow.  I don't have permissions to clone the
> gitbook as a repo, so how would you like me to submit a new gitbook
> section for this protocol?
>

Clone the GitHub repo (https://github.com/keycloak/server_admin_guide) and
send a PR there.

> - Automated testing is going to be a bit of a problem since standing up
> a docker registry requires either a) system binaries, or b) something
> like spinning up a docker image.  Is it acceptable to use the supported
> java docker client and interact with what's effectively a registry
> fixture via the a Keycloak Docker client for the sake of integration
> testing?
>

Can you explain a bit further? I'm not following how you could use the java
docker client to test integration with the registry.

> On Thu, 2016-08-18 at 06:01 +0200, Stian Thorgersen wrote:
> > I'm good with including it in community as long as it's disabled by
> > default, documented and tested ;)
> >
> > On 17 August 2016 at 16:06, Josh Cain <josh.cain at redhat.com> wrote:
> > > I've been in POC mode lately, so the cursory testing I've done has
> > > been limited to manual, high-level tests.  I'd be happy to find a
> > > way to get some useful integrated test for this.
> > >
> > > Right now I'm using 3 things to test - a docker client, a docker
> > > registry, and the keycloak IDP.  Should be able to automate the
> > > registry container start and there's a java library for docker
> > > clients that we can use.  So automated integration testing looks
> > > possible, but I've not gone down that road just yet.  Would
> > > certainly do so if this was going upstream to Keycloak proper.
> > >
> > >
> > > Josh Cain | Software Applications Engineer
> > > Identity and Access Management
> > > Red Hat
> > > +1 256-452-0150
> > >
> > > On Wed, Aug 17, 2016 at 7:56 AM, Bill Burke <bburke at redhat.com>
> > > wrote:
> > > > 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>
> > > > > 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 at r
> > > > > > edhat.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
> > > > > > > > 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&se
> > > > > > > > rvice=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 <sthorg
> > > > > > > > er 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> 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 at lists.jboss.org
> > > > > > > > > > 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
> > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > 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
> >
>