<div dir="ltr">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&#39;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.<div><br></div><div>We&#39;d need to figure out some way to automate testing of it though. We obviously can&#39;t manually test with Docker on a regular basis. Do you have any plans around how to test it?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 August 2016 at 21:24, Josh Cain <span dir="ltr">&lt;<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Couldn&#39;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.<br></div><br></div>We&#39;re going to develop one and push it out such that it&#39;s publicly accessible in any case, I was just curious as to whether the dev team would want to incorporate this into the product.<br><br></div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div data-smartmail="gmail_signature"><div dir="ltr"><span><span class=""><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br></span><a href="tel:%2B1%20256-452-0150" value="+12564520150" target="_blank">+1 256-452-0150</a><br></span></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;m not sure we&#39;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.<div><br></div><div>We did have an idea of creating some repository for extensions. These would be community maintained, not included in product and wouldn&#39;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.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 15 August 2016 at 16:41, Josh Cain <span dir="ltr">&lt;<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Stian,<br><br></div>Docker&#39;s auth V2 (docs link above) is Oauth-ish, but doesn&#39;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 &quot;Missing parameters: response_type&quot; error.  Turns out, Docker sends the GET request like this: <br><br>/auth/realms/redhat-external/p<wbr>rotocol/docker-v2/auth?account<wbr>=jcain&amp;scope=repository%3Acent<wbr>os%3Apull&amp;service=docker-<wbr>registry<br><br></div>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 &#39;service&#39; param to appear as the client_id param to conform to the OAuth spec.<br><br></div>Since it uses different nomenclature, I thought it would be a much cleaner implementation to just implement it as its own protocol.  Didn&#39;t want to muddy up a clean OIDC/OAuth implemention.<br><br></div>Are there workarounds to deal with these differences that I&#39;m missing?<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><span><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br><a href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1 843-737-1735</a><br></span></div></div></div>
<br></span><div><div><div class="gmail_quote">On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;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?</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 12 August 2016 at 15:31, Josh Cain <span dir="ltr">&lt;<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hi All,<br><br></div>We want to use Keycloak as the IDP/Token issuer for authentication with a docker registry as per the specification found here:<br><br><a href="https://docs.docker.com/registry/spec/auth/" target="_blank">https://docs.docker.com/regist<wbr>ry/spec/auth/</a> <br><br></div>I&#39;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&#39;d be happy to push back upstream.<span><font color="#888888"><br><div><div><div><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br><a href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1 843-737-1735</a><br></span></div></div></div>
</div></div></div></font></span></div>
<br></div></div><span>______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/keycloak-dev</a><br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>