[keycloak-dev] kcinit screencast

[Stian Thorgersen]

On 22 March 2018 at 06:42, Bill Burke <bburke at redhat.com> wrote:

> On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Better idea than what? The server generated key?
> >
>
> I'm saying that exchanging with a refresh-token removes the need for a
> confidential client.
>
> > Does it still need a confidential client? I think that would be a
> blocking
> > point as I can't see the admin creating a client per-user that wants to
> use
> > kcinit. Nor do I think users should have to deal with yet another
> > credential.
> >
>
> I also don't like the idea of an admin creating a client per-user,
> hence the previous idea of a persistent "device token".  Like for
> instance with my iTunes app, has a menu item "Authorize this
> computer".  Making purchaes still requires me to enter in my user
> credentials.
>
> The solution can already work with public clients.    The
> "refresh_token" tweak I described just makes things more secure.
>
> > I don't quite understand why the token exchange service is needed at
> all. In
> > the web browser we allow SSO logins by a simple cookie. Why not just do
> > something similar for kcinit? It gets a cookie (or some sort of token)
> that
> > can be used to call direct grant again. Seems so much simpler than using
> > token exchange here.
> >
>
> I was originally going to use your idea...You proposed it months
> ago...BUT...
>
> You need to revisit how the browser handles an SSO session... Even if
> the cookie is set, each confidential client in the SSO sesssion must
> provide its credentials in the code to token flow to get an access
> token.  Your proposal is NOT the same thing as a browser SSO session.
> Your proposal basically grants a public client to be able to exchange
> for any token it wants.   I hope you see the security implications of
> that.
>

I fully understand how the browser handles the SSO session. I don't think
you need to educate me on that.

What I had in mind was that there would be public clients for each use-case
of kcinit. That could be:

* kc-admin-cli - to interact with KC admin endpoints
* os-cli - to interact with OS endpoints
* etc..

That allows folks to use kcinit configured with any of the above clients.
Then you simply get your "SSO token" when you do kclogin. After that you
can use direct grant to obtain tokens for each of the clients/use-cases for
kcinit. To me that is much simpler to setup and doesn't introduce any
security impact beyond what we have today (anyone that can obtain an SSO
token probably has access to the user credentials anyways).

Anyone that has the user credentials can already do this today for all
public clients. So there's no additional leak here. It's much simpler to
setup as you don't need to have a special kcinit client that is setup to be
able to exchange with the other apps.

That being said me may just be discussing a mute point here. I would expect
most uses of kcinit would be driven through one specific CLI, which should
have its own client in Keycloak. The users should probably login to each
separately and any SSO between CLIs may not be that useful.


>
> Token exchange is only one simple HTTP request, which from a client
> coding perspective is not more complex than your proposal.   There is
> some complexity in the admin console setup.  Currently you can grant
> permission to a client to be able to exchange any token for any
> client.  OR...You can have more fine grain control and explicitly
> grant permission for a smaller set. IMO, this is a much better
> solution than having a "special token" that can get a token to invoke
> on any service.  Wouldn't your proposal require granting permission to
> the public client to be able to ask for this "special token"?  Do you
> see how similar your proposal is to the existing solution?
>
> Also, token exchange is not required at all if the initial token has
> permissions to invoke on any service already.  I know some people are
> using Keycloak in this way.  For instance, with kubernetes+keycloak
> integration, you just need Keycloak to validate the username string.
> Kubernetes can grant permission to a username string to adminstrate
> kubernetes.  Hope I'm making sense.
>
> Finally, kcinit would need token exchange to be able to bridge to
> external token architectures.  Login with Keycloak, exchange for an
> OpenStack Keystone token so you can invoke on OpenStack services.
>
> Thanks for the feedback.
>
> --
> Bill Burke
> Red Hat
>