[keycloak-dev] kcinit screencast

[Stian Thorgersen]

You've convinced me and I agree that token exchange is the way to go. Thanks
for entertaining me ;)

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

> On Thu, Mar 22, 2018 at 4:24 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >
> > 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.
> >
>
> This is a good discussion.  Here's some things to think about:
>
> * Are "SSO Tokens" available by default?  Or must you grant a client
> permission to request an SSO Token?  If "SSO Tokens" are on, out of
> the box, then SSO tokens would only be grantable through direct grant
> requests.  Otherwise, any client would be able to request them through
> the code to token flow and you have your leak again.  If you can't use
> code to token flow, then you can't give kcinit the option to launch a
> browser to complete a required action (i.e. the otp config required
> action which is much easier to set up within a browser).  So can we
> agree that SSO tokens must be enabled individually for each and every
> client that wants them?
>
> Is a token exchange implementation actually more difficult?  Not sure.
> Let's goo down the setup checklist for each.
>
> SSO TOKEN CHECKLIST:
>
> - create a kcinit client.
> - Enable "SSO tokens for kcinit client
> - Register  "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri
> - For each REST API that has an existing confidential or bearer only client
>        * create a new public client for it.
>        * This new public client must have same client scopes, role
> scopes, and protocol mappers
>        * Alternatively, instead of creating a new public client, we
> could just modify the existing client to make it public.
> - Add client scopes, role scopes, and protocol mappers as required for
> each REST API that does NOT have an existing client
>
> TOKEN EXCHANGE CHECKLIST:
>
> Checklist for token exchange:
> - create 'kcinit' client.
> - Register "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri
>
> - Give permission to "kcinit" to exchange for any client
>
> OR
>
> - For each REST API that has an existing confidential or bearer only client
>   * Give permissiont o "kcinit" to exhcnage for existing client.  We
> could potentially optimize out this step if "kcinit" is already
> granted a superset of the client and role scopes the target client
> requires.
>
> - Add client scopes, role scopes, and protocol mappers as required for
> each REST API that does NOT have an existing client
>
>
> COMPARISON:
>
> * SSO Tokens require an extra step in kcinit client setup as you have
> to know to enable SSO Tokens.
> * SSO Tokens require public clients, token exchange does not
> * Token exchange is potentially less config steps if you grant
> permission to kcinit to exchange for any client or kcinit already has
> a superset of client and role scopes.  SSO Tokens still require
> setting up public clients.
> * Number of configuration steps will generally be pretty equal for
> both sso tokens and token exchange implementations as SSO Tokens still
> require setting up of public clients.
> * Token exchange option uses existing solutions.  SSO Tokens require
> new architecture.
>
> You made me think real hard on this, but I still like token exchange
> better.  Some of this I had already thought out months ago, but some I
> hadn't.  I still think I made the right design decisions.
>
> I'm going to modify token exchange so that public clients can only
> exchange refresh tokens and make some general feature improvements to
> the client that Pedro thinks are necessary.  You think adding a
> disabled "kcinit" client would be useful too?
>

+1 A disabled kcinit would be helpful to give folks a quick starting point


>
> > 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.
> >
>
> Or this is mute because the token generated for "kcinit" could be
> created with required claims to invoke on variety of backends.
>

True. The default and most used case will most likely be to have a client
that has all required claims, then use token exchange for more advanced
use-cases.


>
> --
> Bill Burke
> Red Hat
>