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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >

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(a)redhat.com <mailto: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 <tel:%2B1%20256-452-0150> On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen <sthorger(a)redhat.com <mailto: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(a)redhat.com <mailto: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 <tel:%2B1%20843-737-1735> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen <sthorger(a)redhat.com <mailto: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(a)redhat.com <mailto: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/ <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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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 <%2B1%20256-452-0150> >> >> On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; >> 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(a)redhat.com&gt; 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 <%2B1%20843-737-1735> >>>> >>>> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen <sthorger(a)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(a)redhat.com&gt; 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 <%2B1%20843-737-1735> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>> >>> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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?

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

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(a)redhat.com&gt; 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(a)redhat.com&gt; > > 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(a)redhat.com&gt; > > > > 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@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(a)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(a)redhat.com&gt; 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(a)lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >