On 22 March 2018 at 06:42, Bill Burke <bburke(a)redhat.com> 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.
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