[keycloak-dev] Docker Protocol?

[Josh Cain]

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/20160816/22673493/attachment-0001.html