[keycloak-user] Announce - Secret Store

[Stian Thorgersen]

Another interesting aspect of this is that it can be useful in IoT.

In IoT the devices themselves are often pretty dumb, they have small amount
of storage and don't even talk http. The hub they connect to is generally
more beefy and talks both zigbee (or whatever) and http. With IoT devices
it would work something like:

1. User registers a new IoT device through some sort of flow (click a
button on the hub, through an app on the smartphone, through the web
browser on the hub portal, or whatever)
2. The hub creates a new "device" account for it in Keycloak, and also gets
tokens from KC (refresh or offline whatever). It stores the refresh/offline
token permanently, but access token only in memory
3. The hub also creates a short token (token UUID, or key/secret pari,
whatever)
4. The hub sends the small short token to the device
5. The device now only needs to store this short token and also only send
this short token
6. The hub looks up the real token based on the uuid or key/secret pair,
and swaps it in any outgoing request

Benefits here is that a small IoT device can communicate to a REST service
secured with bearer tokens without having to deal with large bearer tokens,
refreshing the token, etc..

On 20 January 2016 at 18:50, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/20/2016 11:44 AM, Juraci Paixão Kröhling wrote:
> > On 20.01.2016 17:12, Bill Burke wrote:
> >> What you are describing MAKES ZERO SENSE.  From your document:
> >>
> >> "A token is created when an user reaches the path
> >> |/secret-store/v1/tokens/create| via GET (or passing the username and
> >> password as Basic authentication via POST) and stored into a Cassandra
> >> data store:"
> >>
> >> You are doing EXACTLY what the direct grant REST api does except you are
> >> using basic auth.   I still don't see the purpose of this service.
> > Those are performed in different steps. The user creates this token via
> > an UI (or CLI, if needed), then use this key/secret as the credentials
> > on the client.
> >
> > The client has no knowledge about Keycloak, OAuth, or about any meta
> > data that was embedded into this opaque token. All it cares is that it's
> > going to call the end service using basic auth.
> >
> > The secret store is *not* for every application: it's targeted to
> > clients where OAuth handling is costly, undesirable or even impossible
> > (like legacy applications). So, instead of entering the user's own
> > credentials there, the key/secret are used instead.
> >
> > Our "metrics collector agent" is the main target for this: the knowledge
> > about auth doesn't belong there. All it needs to know is an "user" and
> > "password", which are the "key" and "secret" for the token. Where
> > Keycloak is, how to create an access token from an offline token, how
> > long to keep an access token, and so on is made at the secret store, as
> > we need to save every processing cycle possible, to not badly influence
> > a server that is being monitored (and possibly, already in a bad shape).
> >
> > Of course, if you can live with your password being stored in plaintext
> > on the clients, you don't need the secret store. But honestly, that
> > seems ridiculous.
> Thanks for the explanation and sorry if I sounded rude.  We have people
> suggesting crazy redundant shit all the time and I thought this just
> might have been yet another case of this.  Makes sense now.  Something
> interesting that we should add to Keycloak as an optional service
> sometime in the future.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160120/7c608014/attachment.html