1:50 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I'm building a secret store application that will sit in front of
Hawkular and will be responsible for replacing API keys into actual
Keycloak authentication data.
Based on the suggestions from Stian, the current code does the following
:
- - User logs in Hawkular via Keycloak
- - Once the user wants to create a new application key/secret, the user
is redirected to /secret-store/tokens/create , which takes the KC
authentication data and stores the refresh_token into the database,
creating a new key/secret
- - User configures an external application (like a monitoring agent in
a server), adding this key/secret to its configuration
- - The agent makes a call to the Hawkular backend, sending this key/secre
t
- - An undertow filter gets this key/secret from the request, fetches
the refresh_token from the database, gets a bearer token from Keycloak
based on this refresh_token and sets it to the request's context (ie:
replacing the Authorization header)
- - Keycloak uses this bearer token to perform what it needs to do
- - Request reaches the Hawkular backend
It all works, but the session from the *user* (second step) eventually
expires, causing the refresh_token to be invalid[1].
So, the question is whether this token is indeed supposed to be
attached to an user session, or if it's a bug. If the behavior I'm
seeing is the correct one, what could be a proper way to store a token
so that it can be replaced at a later time?
1 - http://git.io/vLAtF
Best,
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJViUgHAAoJEDnJtskdmzLMCIsH/iOeGmCDANgjvliyeKMWcx0/
j0cFdJuENBqzgPRlj0tSSJeFZeNnIs07ARJk2E0Xoq1D2gSq3KAw3hTOq7nPNfOk
SoG5f1dLDkwCB8a+d/IGNfPw6Tmbzn0i2kwRSbhSJdfYCDxg9xiMPnV2MjvunPYa
f6sXHz0yZjwylis3UuBw7WUNr1wAYOpjfmdBmt0B6hEqBXbIZflX2OEhim7dC+PQ
WBx4lobqWWR+pMF12oabngNPLoE1r8SGSJkkiusMZxaTIWOViiHIYkRzVcul32z7
1OI0EOHnnv4YJ1rzc9frAIu7EPZq0i4BM1YT9pRBlNFBWH/ZQawEyCN6KCrNHDI=
=EA+F
-----END PGP SIGNATURE-----
4:50 p.m.
Hi,
Refresh tokens should expire, but we will be adding offline tokens at some point which
won't expire until revoked by the user or admin.
In the mean time you can set a high level for the sso expiration.
When do you need to have a proper offline token?
----- Original Message -----
From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
To: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 23 June, 2015 1:50:31 PM
Subject: [keycloak-user] Refresh token - should it expire?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I'm building a secret store application that will sit in front of
Hawkular and will be responsible for replacing API keys into actual
Keycloak authentication data.
Based on the suggestions from Stian, the current code does the following
:
- - User logs in Hawkular via Keycloak
- - Once the user wants to create a new application key/secret, the user
is redirected to /secret-store/tokens/create , which takes the KC
authentication data and stores the refresh_token into the database,
creating a new key/secret
- - User configures an external application (like a monitoring agent in
a server), adding this key/secret to its configuration
- - The agent makes a call to the Hawkular backend, sending this key/secre
t
- - An undertow filter gets this key/secret from the request, fetches
the refresh_token from the database, gets a bearer token from Keycloak
based on this refresh_token and sets it to the request's context (ie:
replacing the Authorization header)
- - Keycloak uses this bearer token to perform what it needs to do
- - Request reaches the Hawkular backend
It all works, but the session from the *user* (second step) eventually
expires, causing the refresh_token to be invalid[1].
So, the question is whether this token is indeed supposed to be
attached to an user session, or if it's a bug. If the behavior I'm
seeing is the correct one, what could be a proper way to store a token
so that it can be replaced at a later time?
1 - http://git.io/vLAtF
Best,
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJViUgHAAoJEDnJtskdmzLMCIsH/iOeGmCDANgjvliyeKMWcx0/
j0cFdJuENBqzgPRlj0tSSJeFZeNnIs07ARJk2E0Xoq1D2gSq3KAw3hTOq7nPNfOk
SoG5f1dLDkwCB8a+d/IGNfPw6Tmbzn0i2kwRSbhSJdfYCDxg9xiMPnV2MjvunPYa
f6sXHz0yZjwylis3UuBw7WUNr1wAYOpjfmdBmt0B6hEqBXbIZflX2OEhim7dC+PQ
WBx4lobqWWR+pMF12oabngNPLoE1r8SGSJkkiusMZxaTIWOViiHIYkRzVcul32z7
1OI0EOHnnv4YJ1rzc9frAIu7EPZq0i4BM1YT9pRBlNFBWH/ZQawEyCN6KCrNHDI=
=EA+F
-----END PGP SIGNATURE-----
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
5:12 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/23/2015 04:50 PM, Stian Thorgersen wrote:
In the mean time you can set a high level for the sso expiration.
That would work for now, but note that if an user logs out or if the
session expires for some reason, the token is automatically deemed as
expired as well (invalid_grant, actually). So, it's not about the
token expiration itself, but about the session expiration:
http://git.io/vLAtF
When do you need to have a proper offline token?
Tough question :-) I'd say that we'd absolutely need this by
September/October, but of course, the sooner the better as it touches
an important part of the system.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJViXdOAAoJEDnJtskdmzLMNgEH/jfdVPJQyljkIbbxUlcxo3H3
9RBqzPtpb8142Ts6eJR1lwPg82KEjtycVjGuwggkJINPolhtgVploZPH9bKe7kiN
7GFAEPhT9FPSKUv09oIR1zz0hl9vu9G/Qv35UmWue1JCzTPtRlUYx9cYBS/Ze4Ps
+Y/tXgVbLwrx/y2xOVpAEH2giPuGP9VYYWNMCF3vnzISnLjhaEwEK91vHrfwWKEY
0+KAq7NDO40049FeFAMwsZ1AzlX+CoK54NdR1q7YQ8kAH88bweA8J/NnM6dySaTN
Omf6EsxJMWLMXA4Yya5r8ls+K0ZeyJrQqEw01qrTtpu8q1wp1rfrIk8zjknNZ1I=
=G+Um
-----END PGP SIGNATURE-----
5:14 p.m.
----- Original Message -----
From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 23 June, 2015 5:12:14 PM
Subject: Re: [keycloak-user] Refresh token - should it expire?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/23/2015 04:50 PM, Stian Thorgersen wrote:
> In the mean time you can set a high level for the sso expiration.
That would work for now, but note that if an user logs out or if the
session expires for some reason, the token is automatically deemed as
expired as well (invalid_grant, actually). So, it's not about the
token expiration itself, but about the session expiration:
http://git.io/vLAtF
Indeed that's the intent. All non-offline tokens are linked to the current users
session.
> When do you need to have a proper offline token?
Tough question :-) I'd say that we'd absolutely need this by
September/October, but of course, the sooner the better as it touches
an important part of the system.
We'll try to get it in for 1.5 - which should be end of August.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJViXdOAAoJEDnJtskdmzLMNgEH/jfdVPJQyljkIbbxUlcxo3H3
9RBqzPtpb8142Ts6eJR1lwPg82KEjtycVjGuwggkJINPolhtgVploZPH9bKe7kiN
7GFAEPhT9FPSKUv09oIR1zz0hl9vu9G/Qv35UmWue1JCzTPtRlUYx9cYBS/Ze4Ps
+Y/tXgVbLwrx/y2xOVpAEH2giPuGP9VYYWNMCF3vnzISnLjhaEwEK91vHrfwWKEY
0+KAq7NDO40049FeFAMwsZ1AzlX+CoK54NdR1q7YQ8kAH88bweA8J/NnM6dySaTN
Omf6EsxJMWLMXA4Yya5r8ls+K0ZeyJrQqEw01qrTtpu8q1wp1rfrIk8zjknNZ1I=
=G+Um
-----END PGP SIGNATURE-----
12:14 p.m.
Stian, Keycloak team,
Is the target date for offline tokens still realistic?
- Juca.
On 06/23/2015 05:14 PM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-user(a)lists.jboss.org
> Sent: Tuesday, 23 June, 2015 5:12:14 PM
> Subject: Re: [keycloak-user] Refresh token - should it expire?
>
> On 06/23/2015 04:50 PM, Stian Thorgersen wrote:
>> When do you need to have a proper offline token?
>
> Tough question :-) I'd say that we'd absolutely need this by
> September/October, but of course, the sooner the better as it touches
> an important part of the system.
We'll try to get it in for 1.5 - which should be end of August.
12:52 p.m.
We still aim to get this included in 1.5, which is scheduled for early September. It may
slip to 1.6 which is scheduled for early October.
----- Original Message -----
From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 18 August, 2015 12:14:34 PM
Subject: Re: [keycloak-user] Refresh token - should it expire?
Stian, Keycloak team,
Is the target date for offline tokens still realistic?
- Juca.
On 06/23/2015 05:14 PM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-user(a)lists.jboss.org
>> Sent: Tuesday, 23 June, 2015 5:12:14 PM
>> Subject: Re: [keycloak-user] Refresh token - should it expire?
>>
>> On 06/23/2015 04:50 PM, Stian Thorgersen wrote:
>>> When do you need to have a proper offline token?
>>
>> Tough question :-) I'd say that we'd absolutely need this by
>> September/October, but of course, the sooner the better as it touches
>> an important part of the system.
>
> We'll try to get it in for 1.5 - which should be end of August.
>
8:34 p.m.
Will the option to create an offline token be client specific? For example, client A
should follow realm-wide expirations but client B should be able to issue offline refresh
tokens.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<http://www.sigstr.com/>
On Aug 18, 2015, at 7:14 AM, Juraci Paixão Kröhling
<juraci(a)kroehling.de> wrote:
Sounds good, thanks!
- Juca.
On 08/18/2015 12:52 PM, Stian Thorgersen wrote:
> We still aim to get this included in 1.5, which is scheduled for early September. It
may slip to 1.6 which is scheduled for early October.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:46 a.m.
Yes, clients and users have to have permissions to use offline tokens.
Further the client has to explicitly request offline tokens using a scope
query param.
On 13 October 2015 at 20:34, Scott Rossillo <srossillo(a)smartling.com> wrote:
Will the option to create an offline token be client specific? For
example, client A should follow realm-wide expirations but client B should
be able to issue offline refresh tokens.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
[image: Powered by Sigstr] <http://www.sigstr.com/>
On Aug 18, 2015, at 7:14 AM, Juraci Paixão Kröhling <juraci(a)kroehling.de>
wrote:
Sounds good, thanks!
- Juca.
On 08/18/2015 12:52 PM, Stian Thorgersen wrote:
We still aim to get this included in 1.5, which is scheduled for early
September. It may slip to 1.6 which is scheduled for early October.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
9:43 a.m.
Hi,
keycloak-user-bounces(a)lists.jboss.org wrote on 23/06/2015 16:50:57:
Refresh tokens should expire, but we will be adding offline tokens
at some point which won't expire until revoked by the user or admin.
do you have any idea how this feature will look like? I'm asking because I
will need to cover a use case in the near future, where offline processes
(e.g. periodic exports) need to access services on behalf of a user. In
other words, they need to access data with the roles of the user who
created the process initially, and as the roles are encoded in the token
they actually need to get hold of an access token for that user. Refresh
token were our first idea, but our concern was that we needed the user to
be involved in issuing the refresh token, as the service that executes the
offline processes is not the service the user authenticates with. We use
an api-gateway between the backend services and the UI. But we don't want
to expose such details about the involved microservices to the user. And
as I learned from this thread, the refresh tokens will also expire, which
is also not an option for us. Those processes also need to run when the
user is in vacation for 3 weeks.
I have the feeling that offline tokens would be what we actually need in
our use case. But I think it would be important for some use cases to
allow for issuing of those tokens without user intervention. I think of
having an API that allows a client to request an offline token on behalf
of a user (e.g. by providing a valid access token). Obviously, clients
would need to be enabled explicitly for using such API.
I understand that in typical OAuth flows you want the user to be involved
in such processes, but in an enterprise setting and with a microservices
architecture I would prefer to not bother the user with having to
authorize backend services that he shouldn't even know of.
I would really be interested in how other people solve such scenarios (or
if they do it at all) and what you think of such an API.
Thanks and best regards
Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters |
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de
| WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie
nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution
of the material in this e-mail is strictly forbidden.
3 p.m.
We'll be adding service accounts in the near future, that'll provide a way for
clients to obtain a token on behalf of themselves. There will be a special linked user to
the client. Clients can obtain this through the client credential grant (see oauth2 for
more details) and use a secret or pub/priv keypair to authenticate.
For a client to get a token on behalf of a user the user will have to either enter
username/pass in a cli and you'd use resource owner credential grant (again see oauth2
for more details) or you'd use the normal redirect based flow.
For the above once we add offline tokens this will only be required as an initial setup as
the "refresh token" will not expire until the user goes in and revokes access to
the appliction.
----- Original Message -----
From: "Carsten Saathoff"
<Carsten.Saathoff(a)kisters.de>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>,
keycloak-user(a)lists.jboss.org
Sent: Wednesday, 24 June, 2015 3:43:59 AM
Subject: Re: [keycloak-user] Refresh token - should it expire?
Hi,
keycloak-user-bounces(a)lists.jboss.org wrote on 23/06/2015 16:50:57:
> Refresh tokens should expire, but we will be adding offline tokens
> at some point which won't expire until revoked by the user or admin.
do you have any idea how this feature will look like? I'm asking because I
will need to cover a use case in the near future, where offline processes
(e.g. periodic exports) need to access services on behalf of a user. In
other words, they need to access data with the roles of the user who
created the process initially, and as the roles are encoded in the token
they actually need to get hold of an access token for that user. Refresh
token were our first idea, but our concern was that we needed the user to
be involved in issuing the refresh token, as the service that executes the
offline processes is not the service the user authenticates with. We use
an api-gateway between the backend services and the UI. But we don't want
to expose such details about the involved microservices to the user. And
as I learned from this thread, the refresh tokens will also expire, which
is also not an option for us. Those processes also need to run when the
user is in vacation for 3 weeks.
I have the feeling that offline tokens would be what we actually need in
our use case. But I think it would be important for some use cases to
allow for issuing of those tokens without user intervention. I think of
having an API that allows a client to request an offline token on behalf
of a user (e.g. by providing a valid access token). Obviously, clients
would need to be enabled explicitly for using such API.
I understand that in typical OAuth flows you want the user to be involved
in such processes, but in an enterprise setting and with a microservices
architecture I would prefer to not bother the user with having to
authorize backend services that he shouldn't even know of.
I would really be interested in how other people solve such scenarios (or
if they do it at all) and what you think of such an API.
Thanks and best regards
Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters
| Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail:
Carsten.Saathoff(a)kisters.de | WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
9:14 a.m.
Hi,
Stian Thorgersen <stian(a)redhat.com> wrote on 24/06/2015 15:00:18:
We'll be adding service accounts in the near future, that'll
provide
a way for clients to obtain a token on behalf of themselves. There
will be a special linked user to the client. Clients can obtain this
through the client credential grant (see oauth2 for more details)
and use a secret or pub/priv keypair to authenticate.
that sounds great.
For a client to get a token on behalf of a user the user will have
to either enter username/pass in a cli and you'd use resource owner
credential grant (again see oauth2 for more details) or you'd use
the normal redirect based flow.
For the above once we add offline tokens this will only be required
as an initial setup as the "refresh token" will not expire until the
user goes in and revokes access to the appliction.
That's actually the initial setup that I would like to avoid. If we talk
about social websites this flow makes absolute sense, as I as the user
want to control what data can be accessed by external services. However,
in an enterprise application the user shouldn't be bothered with single
microservices IMO. Therefore, when I ask the user to authorise some
arbitrary backend service to access some data, the user will probably be
surprised or, even worse, confused.
Currently I only see three possible solutions:
1. Do it as you propose and implement the OAuth flow.
2. Add some additional API and options to allow clients to request access
tokens on behalf of users (maybe with reduced privileges only).
3. Somehow let the service figure out the access rights of the user, e.g.
by using the admin API (haven't really checked whether that would work at
all).
I don't like 3 because a) I don't want to provide admin privileges to my
services and b) I don't like the fact that authorisation would work
differently in that case. I definitely prefer 2 over 1, because I think it
will provide the best user experience. My hope was that there is some
other option to handle that use case that I wasn't aware of.
As a general question, would such a feature fit into keycloak, or is out
of consideration because it is not standardized?
best
Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters |
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de
| WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie
nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution
of the material in this e-mail is strictly forbidden.
3116
days inactive
3229
days old
11 comments
5 participants
participants (5)
-
Carsten Saathoff -
Juraci Paixão Kröhling -
Scott Rossillo -
Stian Thorgersen -
Stian Thorgersen