9:06 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev