[keycloak-user] Recommendations for protecting REST service with bearer token and basic auth

[Stian Thorgersen]

----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Monday, 24 November, 2014 10:12:06 AM
> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 11/24/2014 09:44 AM, Stian Thorgersen wrote:
> > There's still some unresolved issues here:
> > 
> > * Never expire isn't good - it should be a longer expiration time *
> > Grant page should ask the user to give the application offline
> > access * User needs some way to revoke the access to the
> > application in the future * Should tokens be unlinked to a user
> > session, or should it be associated with a special user session
> > (just setting a long expiration time for refresh tokens has no
> > effect if user session expires)
> > 
> > I'm also not sure what your use-case is, is this a bash script that
> > acts on behalf of the user? or is it a server backend script? If
> > it's the first the flow you're suggesting works, but if it's the
> > other it's not the correct flow.
> 
> My concrete case is for RHQ Metrics. A system administrator would
> install RHQ Metrics backend on a server and deploy a number of nodes
> on a cloud or a farm. Each node would send metrics to the backend. Out
> of the box, we'll provide some metrics collectors, like an Agent for
> Wildfly. But the system administrator could also build shell scripts
> that would gather custom information from their systems. For instance,
> they might have a in-house daemon for "foo" and would parse the
> foo.log for some data, sending it to the Metrics backend. Ideally,
> this would be done with a simple curl call, but I'm getting hopeless
> on this :)
> 
> Ideally, a token/key/secret/code that I have on the nodes wouldn't
> expire. I'm fine with exchanging the code/secret with a token, but
> requiring a refresh of this "stable" code from time to time could
> cause some troubles. For instance, a node that hasn't received this
> updated stable code would stop reporting data.
> 
> About service accounts vs. user specific offline access: for me, as a
> consumer of this feature, I couldn't care less. I'd *prefer* to have
> it as a service account, as I could possibly better manage it, but any
> solution would be fine.

There's a pretty big difference. Offline access gives applications permissions to act on behalf of a user, while service accounts allows users to act on behalf of themselves.

Offline access is not the way to go for your use-case. We should add some sort of service accounts to Keycloak, they would:

* Enable authenticating with secret, certificate or jwt/jws (also shouldn't require a client to authenticate twice)
* Probably have different semantics for user sessions. It makes sense that a regular user is logged-out after a few days, but does that make sense for an service account?

I'd say a service account should be a "special" user rather than something completely different.

You can get this use-case to work relatively well with Keycloak as is for now though. Just use a regular user with a longish random password (or even better set the password to the client secret). Your bash script will have to be able to deal with obtaining a token through the direct grant mechanism in either case, and it'll also have to deal with expiration of tokens and refreshing tokens.

Long term it may even make sense to allow KC to manage registration of devices like this. A node could generate a certificate, post some info to Keycloak to request authenticating, then an admin could grant the access. This same mechanism could be useful for IoT.

> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBCgAGBQJUcvZmAAoJEDnJtskdmzLM+o8H/jTAlNhnsSJTt842ThpRNcql
> mTDzfGRMXMcyFJBK8kYWRFY3NY/B2n42ux8S6q/ZvxKLKye5CtbrP7rKwQuoIFZ5
> BK+KQisPgYGw3CSwjB0TRW/5BawKXIoLgMRmV/fNGx8D/BeTOordyfrhBKULdKpk
> +fPAsh1JdXDMV9EieQQGuX9HLhp5makG0FRVnMmw+NA967vgcPEHLBz0/NQO23I1
> 6HlobrH/07Z64bjcdYanxlGidJ2LIYh47lYnXHPhUSjoaK9uz5ZNZ8WQ3GW0Xg36
> A/kEtexkMITmNamExnJw2E1xAMvX9lso5UjTmxH9AgMPZGFZ4Znybc7ecm+V7mE=
> =6yHk
> -----END PGP SIGNATURE-----
>