[keycloak-dev] Docker Protocol?

[Stian Thorgersen]

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 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 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&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 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
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/29ed2a1c/attachment.html