[keycloak-dev] Docker Protocol?

Thu Aug 18 00:01:58 EDT 2016

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 at redhat.com> 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 at redhat.com> 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 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 <%2B1%20256-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 <%2B1%20843-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 <%2B1%20843-737-1735>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> 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/20160818/3a2850a0/attachment-0001.html 