Re: [keycloak-dev] kcinit screencast

On Thu, Mar 22, 2018 at 4:24 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On 22 March 2018 at 06:42, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >> On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen <sthorger(a)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?

> 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.

-- Bill Burke Red Hat