Finally got some time to try to wrap this one up, but I had a few
questions:
- Was looking to add a new section to the server-administration-guide
(7.4, under SSO Protocols), but am not sure how to do that using
GitBooks. I can make comments, but am unsure how a new page would be
added in a PR-style flow. I don't have permissions to clone the
gitbook as a repo, so how would you like me to submit a new gitbook
section for this protocol?
- Automated testing is going to be a bit of a problem since standing
up
a docker registry requires either a) system binaries, or b) something
like spinning up a docker image. Is it acceptable to use the supported
java docker client and interact with what's effectively a registry
fixture via the a Keycloak Docker client for the sake of integration
testing?
Can you explain a bit further? I'm not following how you could use the java
docker client to test integration with the registry.
On Thu, 2016-08-18 at 06:01 +0200, Stian Thorgersen wrote:
> 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(a)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(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
> > > > >
> > > > > On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen
<sthorger@r
> > > > > edhat.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&se
> > > > > > > rvice=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
<sthorg
> > > > > > > er(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@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(a)lists.jboss.org
> > > > > > > > >
https://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
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > >
https://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
>