9:15 a.m.
For Hawkular, we were in the need of a simplified way for a REST client
to communicate with our backend. After discussing this with Stian, we
started the "secret-store" module, which was just spun off of Hawkular
into a "standalone" project.
Secret Store is a module for scenarios where the whole OAuth procedure
might be undesirable or not feasible on the client side.
The Secret Store has two sides:
1) a REST endpoint to create opaque tokens backed by OAuth Offline
Tokens composed of a key and secret;
2) An Undertow filter/Proxy server, that translates the opaque tokens
into OAuth bearer tokens, rewriting the incoming request. To your
backend, it's transparent whether an opaque token or a proper OAuth
token was used.
More info here: https://github.com/jpkrohling/secret-store
- Juca.
10:32 a.m.
I honestly don't get why you are doing this. I assume you are familiar
with direct grants. Why aren't these enough? Its just a REST call to
keycloak to obtain a token. Honestly, this seems ridiculous.
On 1/20/2016 9:15 AM, Juraci Paixão Kröhling wrote:
For Hawkular, we were in the need of a simplified way for a REST
client
to communicate with our backend. After discussing this with Stian, we
started the "secret-store" module, which was just spun off of Hawkular
into a "standalone" project.
Secret Store is a module for scenarios where the whole OAuth procedure
might be undesirable or not feasible on the client side.
The Secret Store has two sides:
1) a REST endpoint to create opaque tokens backed by OAuth Offline
Tokens composed of a key and secret;
2) An Undertow filter/Proxy server, that translates the opaque tokens
into OAuth bearer tokens, rewriting the incoming request. To your
backend, it's transparent whether an opaque token or a proper OAuth
token was used.
More info here: https://github.com/jpkrohling/secret-store
- Juca.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:57 a.m.
Direct grants require the client to have access to an user's
credentials. On our specific case, having plain text access to the
account credentials are not viewed as very secure by sysadmins. So,
issuing those tokens and making them individually revokable make sense.
On 20.01.2016 16:32, Bill Burke wrote:
I honestly don't get why you are doing this. I assume you are
familiar
with direct grants. Why aren't these enough? Its just a REST call to
keycloak to obtain a token. Honestly, this seems ridiculous.
On 1/20/2016 9:15 AM, Juraci Paixão Kröhling wrote:
> For Hawkular, we were in the need of a simplified way for a REST client
> to communicate with our backend. After discussing this with Stian, we
> started the "secret-store" module, which was just spun off of Hawkular
> into a "standalone" project.
>
> Secret Store is a module for scenarios where the whole OAuth procedure
> might be undesirable or not feasible on the client side.
>
> The Secret Store has two sides:
>
> 1) a REST endpoint to create opaque tokens backed by OAuth Offline
> Tokens composed of a key and secret;
>
> 2) An Undertow filter/Proxy server, that translates the opaque tokens
> into OAuth bearer tokens, rewriting the incoming request. To your
> backend, it's transparent whether an opaque token or a proper OAuth
> token was used.
>
> More info here: https://github.com/jpkrohling/secret-store
>
> - Juca.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
11:12 a.m.
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.
On 1/20/2016 10:57 AM, Juraci Paixão Kröhling wrote:
Direct grants require the client to have access to an user's
credentials. On our specific case, having plain text access to the
account credentials are not viewed as very secure by sysadmins. So,
issuing those tokens and making them individually revokable make sense.
On 20.01.2016 16:32, Bill Burke wrote:
> I honestly don't get why you are doing this. I assume you are familiar
> with direct grants. Why aren't these enough? Its just a REST call to
> keycloak to obtain a token. Honestly, this seems ridiculous.
>
> On 1/20/2016 9:15 AM, Juraci Paixão Kröhling wrote:
>> For Hawkular, we were in the need of a simplified way for a REST client
>> to communicate with our backend. After discussing this with Stian, we
>> started the "secret-store" module, which was just spun off of Hawkular
>> into a "standalone" project.
>>
>> Secret Store is a module for scenarios where the whole OAuth procedure
>> might be undesirable or not feasible on the client side.
>>
>> The Secret Store has two sides:
>>
>> 1) a REST endpoint to create opaque tokens backed by OAuth Offline
>> Tokens composed of a key and secret;
>>
>> 2) An Undertow filter/Proxy server, that translates the opaque tokens
>> into OAuth bearer tokens, rewriting the incoming request. To your
>> backend, it's transparent whether an opaque token or a proper OAuth
>> token was used.
>>
>> More info here: https://github.com/jpkrohling/secret-store
>>
>> - Juca.
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:44 a.m.
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.
- Juca.
11:48 a.m.
Is that not the use-case for the ‘offline tokens’ that Keycloak added
support for recently?
(/me isn’t certain)
-Bob
On Wed, Jan 20, 2016 at 11:44 AM, Juraci Paixão Kröhling <
juraci(a)kroehling.de> 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.
- Juca.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:50 a.m.
On 20.01.2016 17:48, Bob McWhirter wrote:
Is that not the use-case for the ‘offline tokens’ that Keycloak
added
support for recently?
(/me isn’t certain)
Sort of: the offline token is like a refresh token, as in it can only be
used to create access tokens. So, the client needs to know how to get an
access token from an offline token.
- Juca.
12:50 p.m.
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
2:15 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:18 p.m.
IETF already has some work around OAuth2 and IoT. It is interesting
https://tools.ietf.org/html/draft-tschofenig-ace-oauth-iot-00.
Also, I think IoT is usually based and preferable on UDP instead of TCP.
Regards.
Pedro Igor
----- Original Message -----
From: "Stian Thorgersen" <sthorger(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Wednesday, January 20, 2016 5:15:26 PM
Subject: Re: [keycloak-user] Announce - Secret Store
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:50 a.m.
IoT devices are usually ZigBee or some other type of mesh protocol. It's
clever stuff, my light bulbs can relay signals from each other, my laptops
can't.
On 20 January 2016 at 21:18, Pedro Igor Silva <psilva(a)redhat.com> wrote:
IETF already has some work around OAuth2 and IoT. It is interesting
https://tools.ietf.org/html/draft-tschofenig-ace-oauth-iot-00.
Also, I think IoT is usually based and preferable on UDP instead of TCP.
Regards.
Pedro Igor
----- Original Message -----
From: "Stian Thorgersen" <sthorger(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Wednesday, January 20, 2016 5:15:26 PM
Subject: Re: [keycloak-user] Announce - Secret Store
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3015
days inactive
3016
days old
10 comments
5 participants
participants (5)
-
Bill Burke -
Bob McWhirter -
Juraci Paixão Kröhling -
Pedro Igor Silva -
Stian Thorgersen