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
<mailto:josh.cain@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 <tel:%2B1%20256-452-0150>
On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@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
<mailto:josh.cain@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 <tel:%2B1%20843-737-1735>
On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@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 <mailto: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/
<
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 <tel:%2B1%20843-737-1735>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
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