<div dir="ltr"><div>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.<br><br></div>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.<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><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>+1 256-452-0150<br></span></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 17, 2016 at 7:56 AM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Can't you just have "enabled": false in keycloak-server.json for
that provider?<br>
</p><div><div class="h5">
<br>
<div>On 8/17/16 3:41 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<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'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'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?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 16 August 2016 at 21:24, Josh Cain <span dir="ltr"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></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'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'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.<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>
<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>
<br>
<div class="gmail_quote">On Tue, Aug 16, 2016 at 4:19
AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></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'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.
<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'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"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></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'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: <br>
<br>
/auth/realms/redhat-external/p<wbr>rotocol/docker-v2/auth?account<wbr>=jcain&scope=repository%3Acent<wbr>os%3Apull&service=docker-regis<wbr>try<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
'service' 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't want to muddy up a
clean OIDC/OAuth implemention.<br>
<br>
</div>
Are there workarounds to deal with
these differences that I'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"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></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'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"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></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'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.<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>
<br>
<fieldset></fieldset>
<br>
<pre>______________________________<wbr>_________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">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/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>