1:39 a.m.
Hello,
In cloud-native application systems, there are various client applications and those
applications are not the same level (i.e. security level, alliance level, development
level). And generally, a realm manager or a resource server manager wants to set a
different timeout to tokens (access token/refresh token) per client. For example, for a
client which wants to minimize authentication considering usability, we set the timeout of
a refresh token longer enough. For a client which wants to refresh tokens periodically to
mitigate the token interception attack, we set the timeout of a refresh token according to
the client requirement.
Currently, the timeout of an access token can be overridden per client. However, the
timeout of a refresh token (including offline token) cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token (including offline
token) per client.
We'd already tried to implement this just like access token lifespan overriding, and
create JIRA ticket and PR, but Stian recommended that we should discuss this use case and
how to implement in ML, so I opened this thread.
For single sign-on purpose, it is useful to share sessions among clients in a realm.
However, when we implement this, sessions are no longer shared among clients depending on
the settings. And this is useful for API management purpose because, for API management
purpose, tokens (= sessions) are associated with each client, and should be managed per
client.
What do you think about this feature? I would be very happy if you community gives any
kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
3:59 a.m.
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make
sense.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Hello,
In cloud-native application systems, there are various client applications
and those applications are not the same level (i.e. security level,
alliance level, development level). And generally, a realm manager or a
resource server manager wants to set a different timeout to tokens (access
token/refresh token) per client. For example, for a client which wants to
minimize authentication considering usability, we set the timeout of a
refresh token longer enough. For a client which wants to refresh tokens
periodically to mitigate the token interception attack, we set the timeout
of a refresh token according to the client requirement.
Currently, the timeout of an access token can be overridden per client.
However, the timeout of a refresh token (including offline token) cannot be
overridden per client.
We'd like to be able to override the timeout of a refresh token (including
offline token) per client.
We'd already tried to implement this just like access token lifespan
overriding, and create JIRA ticket and PR, but Stian recommended that we
should discuss this use case and how to implement in ML, so I opened this
thread.
For single sign-on purpose, it is useful to share sessions among clients
in a realm.
However, when we implement this, sessions are no longer shared among
clients depending on the settings. And this is useful for API management
purpose because, for API management purpose, tokens (= sessions) are
associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you
community gives any kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:46 a.m.
For authorization code flow it makes no sense at all to have
different session timeouts as it is by definition a shared SSO session. Different security
levels should be controlled things like step-up and authentication timeout, not by having
different session timeouts. Further, I'm not sure if refresh token timeout should be
configurable per-client here as end of the day a new refresh token can easily be obtained
as long as the session is still active.
Clients guarantee to end-users that clients access to end-users' resources only within
the expiration using the tokens. So end-users need to re-login after the expiration and
clients must not refresh tokens after the expiration.
The expiration depends on each client by security reason, or usability reason, or so on.
Therefore regardless of which authorization flows we use, we need to make a difference
between session timeouts.
I'm not particularly found of introducing so many settings on a
client. It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply adding all these
settings on a client may work for you, but I doubt others would understand how and when to
use them, and I think it can easily end up resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship between
UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many relationship, and
this makes it difficult to set session timeout per client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication result appeared
but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
From: Stian Thorgersen <sthorger(a)redhat.com>
Sent: Friday, September 20, 2019 6:00 PM
To: TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different session timeouts as
it is by definition a shared SSO session. Different security levels should be controlled
things like step-up and authentication timeout, not by having different session timeouts.
Further, I'm not sure if refresh token timeout should be configurable per-client here
as end of the day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make sense.
I'm not particularly found of introducing so many settings on a client. It's
difficult to setup and error prone. So this use-case needs to be described properly and we
need to find a decent solution to it. Simply adding all these settings on a client may
work for you, but I doubt others would understand how and when to use them, and I think it
can easily end up resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI
<yoshiyuki.tabata.jy@hitachi.com<mailto:yoshiyuki.tabata.jy@hitachi.com>>
wrote:
Hello,
In cloud-native application systems, there are various client applications and those
applications are not the same level (i.e. security level, alliance level, development
level). And generally, a realm manager or a resource server manager wants to set a
different timeout to tokens (access token/refresh token) per client. For example, for a
client which wants to minimize authentication considering usability, we set the timeout of
a refresh token longer enough. For a client which wants to refresh tokens periodically to
mitigate the token interception attack, we set the timeout of a refresh token according to
the client requirement.
Currently, the timeout of an access token can be overridden per client. However, the
timeout of a refresh token (including offline token) cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token (including offline
token) per client.
We'd already tried to implement this just like access token lifespan overriding, and
create JIRA ticket and PR, but Stian recommended that we should discuss this use case and
how to implement in ML, so I opened this thread.
For single sign-on purpose, it is useful to share sessions among clients in a realm.
However, when we implement this, sessions are no longer shared among clients depending on
the settings. And this is useful for API management purpose because, for API management
purpose, tokens (= sessions) are associated with each client, and should be managed per
client.
What do you think about this feature? I would be very happy if you community gives any
kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907<https://clicktime.syman...
PR is the following.
https://github.com/keycloak/keycloak/pull/6309<https://clicktime.syman...
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev<https://clicktim...
2:44 a.m.
So trying to understand your use-case and simplifying things a bit. You
basically have two (or more) different groups of APIs. Let's call these
low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
don't need to authenticate regularly and a session can last for days (or
weeks). For high-risk APIs they need to authenticate more regularly.
Now this is solved with looking at when the user last authenticated as well
as how the user was authenticated, not by having different session
timeouts. As we don't have step-up autentication support right now, that
leaves us with requiring users to re-authenticate more regularly for the
high-risk API.
Conceptually I can see at least two different ways to achieve the above:
1) Resource Server is responsible for verifying - the UI uses login=promt
and/or max_age to re-authenticate the user when needed. Further, the
resource server needs to check when user authenticate.
2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh
tokens with shorter duration for specific apps/UIs
Option 2 is problematic as the UI may just as well invoke both low-risk and
high-risk APIs. Further, in the future as we add step-up, high-risk may be
asking for step-up authentication, not re-authentication.
On Tue, 24 Sep 2019 at 07:46, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
> For authorization code flow it makes no sense at all to have
different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
Clients guarantee to end-users that clients access to end-users' resources
only within the expiration using the tokens. So end-users need to re-login
after the expiration and clients must not refresh tokens after the
expiration.
The expiration depends on each client by security reason, or usability
reason, or so on.
Therefore regardless of which authorization flows we use, we need to make
a difference between session timeouts.
> I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship
between UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many
relationship, and this makes it difficult to set session timeout per client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication
result appeared but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Keycloak is a SSO solution and we have no plans on introducing per-client
sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Friday, September 20, 2019 6:00 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make
sense.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Hello,
In cloud-native application systems, there are various client applications
and those applications are not the same level (i.e. security level,
alliance level, development level). And generally, a realm manager or a
resource server manager wants to set a different timeout to tokens (access
token/refresh token) per client. For example, for a client which wants to
minimize authentication considering usability, we set the timeout of a
refresh token longer enough. For a client which wants to refresh tokens
periodically to mitigate the token interception attack, we set the timeout
of a refresh token according to the client requirement.
Currently, the timeout of an access token can be overridden per client.
However, the timeout of a refresh token (including offline token) cannot be
overridden per client.
We'd like to be able to override the timeout of a refresh token (including
offline token) per client.
We'd already tried to implement this just like access token lifespan
overriding, and create JIRA ticket and PR, but Stian recommended that we
should discuss this use case and how to implement in ML, so I opened this
thread.
For single sign-on purpose, it is useful to share sessions among clients
in a realm.
However, when we implement this, sessions are no longer shared among
clients depending on the settings. And this is useful for API management
purpose because, for API management purpose, tokens (= sessions) are
associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you
community gives any kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907
<https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2...
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
<https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2...
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2...
8:05 p.m.
So trying to understand your use-case and simplifying things a bit.
You basically have two (or more) different groups of APIs. Let's call these low-risk
APIs and high-risk APIs. When a user invokes the low-risk API they don't need to
authenticate regularly and a session can last for days (or weeks). For high-risk APIs they
need to authenticate more regularly.
This example is a little bit unfitted for our use case.
I give a concrete example.
For example, there are 2 client applications.
Client application A accesses high-risk APIs such as money transfer API.
Client application B accesses low-risk APIs such as balance inquiry API.
In client application A case, it's risky for an end-user to let the client application
to hold a valid refresh token long time because a risk increases which an attacker sends
money using the stolen mobile devices or which an attacker steals the valid refresh token.
Therefore end-user wants to re-authenticate periodically and the client application
guarantees to end-user that it holds a valid refresh token only limited short time.
In client application B case, it's not risky for an end-user to let the client
application to hold a valid refresh token long time because it is not much impact for
end-user that an attacker checks end user's balance. Therefore end-user does not want
to re-authenticate periodically and the client application holds a valid refresh token
long time prioritizing usability.
In the above use case, end-user does not trust client applications completely, so it's
meaningless that client application defines the expiration of a refresh token. And
it's meaningful that authorization server (Keycloak) defines the expiration of a
refresh token.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
From: Stian Thorgersen <sthorger(a)redhat.com>
Sent: Tuesday, September 24, 2019 4:45 PM
To: TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: Re: [keycloak-dev] Override Refresh token lifespan per client
So trying to understand your use-case and simplifying things a bit. You basically have two
(or more) different groups of APIs. Let's call these low-risk APIs and high-risk APIs.
When a user invokes the low-risk API they don't need to authenticate regularly and a
session can last for days (or weeks). For high-risk APIs they need to authenticate more
regularly.
Now this is solved with looking at when the user last authenticated as well as how the
user was authenticated, not by having different session timeouts. As we don't have
step-up autentication support right now, that leaves us with requiring users to
re-authenticate more regularly for the high-risk API.
Conceptually I can see at least two different ways to achieve the above:
1) Resource Server is responsible for verifying - the UI uses login=promt and/or max_age
to re-authenticate the user when needed. Further, the resource server needs to check when
user authenticate.
2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh tokens with
shorter duration for specific apps/UIs
Option 2 is problematic as the UI may just as well invoke both low-risk and high-risk
APIs. Further, in the future as we add step-up, high-risk may be asking for step-up
authentication, not re-authentication.
On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI
<yoshiyuki.tabata.jy@hitachi.com<mailto:yoshiyuki.tabata.jy@hitachi.com>>
wrote:
For authorization code flow it makes no sense at all to have
different session timeouts as it is by definition a shared SSO session. Different security
levels should be controlled things like step-up and authentication timeout, not by having
different session timeouts. Further, I'm not sure if refresh token timeout should be
configurable per-client here as end of the day a new refresh token can easily be obtained
as long as the session is still active.
Clients guarantee to end-users that clients access to end-users' resources only within
the expiration using the tokens. So end-users need to re-login after the expiration and
clients must not refresh tokens after the expiration.
The expiration depends on each client by security reason, or usability reason, or so on.
Therefore regardless of which authorization flows we use, we need to make a difference
between session timeouts.
I'm not particularly found of introducing so many settings on a
client. It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply adding all these
settings on a client may work for you, but I doubt others would understand how and when to
use them, and I think it can easily end up resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship between
UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many relationship, and
this makes it difficult to set session timeout per client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication result appeared
but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Keycloak is a SSO solution and we have no plans on introducing per-client sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
From: Stian Thorgersen <sthorger@redhat.com<mailto:sthorger@redhat.com>>
Sent: Friday, September 20, 2019 6:00 PM
To: TABATA，YOSHIYUKI
<yoshiyuki.tabata.jy@hitachi.com<mailto:yoshiyuki.tabata.jy@hitachi.com>>
Cc: keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different session timeouts as
it is by definition a shared SSO session. Different security levels should be controlled
things like step-up and authentication timeout, not by having different session timeouts.
Further, I'm not sure if refresh token timeout should be configurable per-client here
as end of the day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make sense.
I'm not particularly found of introducing so many settings on a client. It's
difficult to setup and error prone. So this use-case needs to be described properly and we
need to find a decent solution to it. Simply adding all these settings on a client may
work for you, but I doubt others would understand how and when to use them, and I think it
can easily end up resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI
<yoshiyuki.tabata.jy@hitachi.com<mailto:yoshiyuki.tabata.jy@hitachi.com>>
wrote:
Hello,
In cloud-native application systems, there are various client applications and those
applications are not the same level (i.e. security level, alliance level, development
level). And generally, a realm manager or a resource server manager wants to set a
different timeout to tokens (access token/refresh token) per client. For example, for a
client which wants to minimize authentication considering usability, we set the timeout of
a refresh token longer enough. For a client which wants to refresh tokens periodically to
mitigate the token interception attack, we set the timeout of a refresh token according to
the client requirement.
Currently, the timeout of an access token can be overridden per client. However, the
timeout of a refresh token (including offline token) cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token (including offline
token) per client.
We'd already tried to implement this just like access token lifespan overriding, and
create JIRA ticket and PR, but Stian recommended that we should discuss this use case and
how to implement in ML, so I opened this thread.
For single sign-on purpose, it is useful to share sessions among clients in a realm.
However, when we implement this, sessions are no longer shared among clients depending on
the settings. And this is useful for API management purpose because, for API management
purpose, tokens (= sessions) are associated with each client, and should be managed per
client.
What do you think about this feature? I would be very happy if you community gives any
kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907<https://clicktime.syman...
PR is the following.
https://github.com/keycloak/keycloak/pull/6309<https://clicktime.syman...
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev<https://clicktim...
1:55 a.m.
I don't understand what's different with your use-case compared to what I
listed. As I understand it they are both pretty much the same use-case.
In either case different sessions and timeouts are not the correct
solution. Configurable refresh token timeout is probably not a good
solution either, at least not on its own without anything else.
On Wed, 25 Sep 2019 at 03:05, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
> So trying to understand your use-case and simplifying things a
bit. You
basically have two (or more) different groups of APIs. Let's call these
low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
don't need to authenticate regularly and a session can last for days (or
weeks). For high-risk APIs they need to authenticate more regularly.
This example is a little bit unfitted for our use case.
I give a concrete example.
For example, there are 2 client applications.
Client application A accesses high-risk APIs such as money transfer API.
Client application B accesses low-risk APIs such as balance inquiry API.
In client application A case, it's risky for an end-user to let the client
application to hold a valid refresh token long time because a risk
increases which an attacker sends money using the stolen mobile devices or
which an attacker steals the valid refresh token. Therefore end-user wants
to re-authenticate periodically and the client application guarantees to
end-user that it holds a valid refresh token only limited short time.
In client application B case, it's not risky for an end-user to let the
client application to hold a valid refresh token long time because it is
not much impact for end-user that an attacker checks end user's balance.
Therefore end-user does not want to re-authenticate periodically and the
client application holds a valid refresh token long time prioritizing
usability.
In the above use case, end-user does not trust client applications
completely, so it's meaningless that client application defines the
expiration of a refresh token. And it's meaningful that authorization
server (Keycloak) defines the expiration of a refresh token.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Tuesday, September 24, 2019 4:45 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan per
client
So trying to understand your use-case and simplifying things a bit. You
basically have two (or more) different groups of APIs. Let's call these
low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
don't need to authenticate regularly and a session can last for days (or
weeks). For high-risk APIs they need to authenticate more regularly.
Now this is solved with looking at when the user last authenticated as
well as how the user was authenticated, not by having different session
timeouts. As we don't have step-up autentication support right now, that
leaves us with requiring users to re-authenticate more regularly for the
high-risk API.
Conceptually I can see at least two different ways to achieve the above:
1) Resource Server is responsible for verifying - the UI uses login=promt
and/or max_age to re-authenticate the user when needed. Further, the
resource server needs to check when user authenticate.
2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh
tokens with shorter duration for specific apps/UIs
Option 2 is problematic as the UI may just as well invoke both low-risk
and high-risk APIs. Further, in the future as we add step-up, high-risk may
be asking for step-up authentication, not re-authentication.
On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
> For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
Clients guarantee to end-users that clients access to end-users' resources
only within the expiration using the tokens. So end-users need to re-login
after the expiration and clients must not refresh tokens after the
expiration.
The expiration depends on each client by security reason, or usability
reason, or so on.
Therefore regardless of which authorization flows we use, we need to make
a difference between session timeouts.
> I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship
between UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many
relationship, and this makes it difficult to set session timeout per client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication
result appeared but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Keycloak is a SSO solution and we have no plans on introducing per-client
sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Friday, September 20, 2019 6:00 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make
sense.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Hello,
In cloud-native application systems, there are various client applications
and those applications are not the same level (i.e. security level,
alliance level, development level). And generally, a realm manager or a
resource server manager wants to set a different timeout to tokens (access
token/refresh token) per client. For example, for a client which wants to
minimize authentication considering usability, we set the timeout of a
refresh token longer enough. For a client which wants to refresh tokens
periodically to mitigate the token interception attack, we set the timeout
of a refresh token according to the client requirement.
Currently, the timeout of an access token can be overridden per client.
However, the timeout of a refresh token (including offline token) cannot be
overridden per client.
We'd like to be able to override the timeout of a refresh token (including
offline token) per client.
We'd already tried to implement this just like access token lifespan
overriding, and create JIRA ticket and PR, but Stian recommended that we
should discuss this use case and how to implement in ML, so I opened this
thread.
For single sign-on purpose, it is useful to share sessions among clients
in a realm.
However, when we implement this, sessions are no longer shared among
clients depending on the settings. And this is useful for API management
purpose because, for API management purpose, tokens (= sessions) are
associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you
community gives any kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907
<https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2...
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
<https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2...
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2...
4:16 p.m.
Stian:
In reading this thread and the OPs concerns, I see three components that could exert or
express control - the Keycloak server; the application server; and the user.
From reading the OPs concerns, both in the original post and in the later articulation, it
seems as though there is a desire to have the user express what is a high-risk API . . .
"Therefore end-user wants to re-authenticate periodically”, versus your example of
the Application server designating itself as a high-risk for all users.
I agree with your assertion that solving this issue through HTTP session-timeouts would be
problematic, not least of all for SSO type of authentications.
Having the application server specify to the Keycloak server the max-length of a valid
authorization based upon successful authentication, would permit the Keycloak server to
set the “max-age” attribute, whereby refresh tokens would no longer be issued or honored
after that time, leading to a requirement to reauthenticate.
The tricky bit for the OPs scenario is creating a method within the application server for
the user to express this to the application, which could then be conveyed to Keycloak,
which could then be set on the user tokens.
This does lead back to the application server, as you asserted, but I believe that there
would need to be a mechanism, if one does not already exist, for the application server to
communicate this to Keycloak on a per-user basis. It should also be possible for the
Keycloak server to take a configuration element that permits designation of high-risk and
low-risk APIs, in order to interfere with attempts to downgrade authentication strengths
for sensitive applications.
I hope this makes sense.
Regards,
Martin
On Sep 24, 2019, at 23:55 , Stian Thorgersen
<sthorger(a)redhat.com> wrote:
I don't understand what's different with your use-case compared to what I
listed. As I understand it they are both pretty much the same use-case.
In either case different sessions and timeouts are not the correct
solution. Configurable refresh token timeout is probably not a good
solution either, at least not on its own without anything else.
On Wed, 25 Sep 2019 at 03:05, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>> So trying to understand your use-case and simplifying things a bit. You
> basically have two (or more) different groups of APIs. Let's call these
> low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
> don't need to authenticate regularly and a session can last for days (or
> weeks). For high-risk APIs they need to authenticate more regularly.
>
>
>
> This example is a little bit unfitted for our use case.
>
> I give a concrete example.
>
>
>
> For example, there are 2 client applications.
>
> Client application A accesses high-risk APIs such as money transfer API.
>
> Client application B accesses low-risk APIs such as balance inquiry API.
>
>
>
> In client application A case, it's risky for an end-user to let the client
> application to hold a valid refresh token long time because a risk
> increases which an attacker sends money using the stolen mobile devices or
> which an attacker steals the valid refresh token. Therefore end-user wants
> to re-authenticate periodically and the client application guarantees to
> end-user that it holds a valid refresh token only limited short time.
>
>
>
> In client application B case, it's not risky for an end-user to let the
> client application to hold a valid refresh token long time because it is
> not much impact for end-user that an attacker checks end user's balance.
> Therefore end-user does not want to re-authenticate periodically and the
> client application holds a valid refresh token long time prioritizing
> usability.
>
>
>
> In the above use case, end-user does not trust client applications
> completely, so it's meaningless that client application defines the
> expiration of a refresh token. And it's meaningful that authorization
> server (Keycloak) defines the expiration of a refresh token.
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Tuesday, September 24, 2019 4:45 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan per
> client
>
>
>
> So trying to understand your use-case and simplifying things a bit. You
> basically have two (or more) different groups of APIs. Let's call these
> low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
> don't need to authenticate regularly and a session can last for days (or
> weeks). For high-risk APIs they need to authenticate more regularly.
>
>
>
> Now this is solved with looking at when the user last authenticated as
> well as how the user was authenticated, not by having different session
> timeouts. As we don't have step-up autentication support right now, that
> leaves us with requiring users to re-authenticate more regularly for the
> high-risk API.
>
>
>
> Conceptually I can see at least two different ways to achieve the above:
>
>
>
> 1) Resource Server is responsible for verifying - the UI uses login=promt
> and/or max_age to re-authenticate the user when needed. Further, the
> resource server needs to check when user authenticate.
>
> 2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh
> tokens with shorter duration for specific apps/UIs
>
>
>
> Option 2 is problematic as the UI may just as well invoke both low-risk
> and high-risk APIs. Further, in the future as we add step-up, high-risk may
> be asking for step-up authentication, not re-authentication.
>
>
>
> On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
>> For authorization code flow it makes no sense at all to have different
> session timeouts as it is by definition a shared SSO session. Different
> security levels should be controlled things like step-up and authentication
> timeout, not by having different session timeouts. Further, I'm not sure if
> refresh token timeout should be configurable per-client here as end of the
> day a new refresh token can easily be obtained as long as the session is
> still active.
>
>
>
> Clients guarantee to end-users that clients access to end-users' resources
> only within the expiration using the tokens. So end-users need to re-login
> after the expiration and clients must not refresh tokens after the
> expiration.
>
> The expiration depends on each client by security reason, or usability
> reason, or so on.
>
> Therefore regardless of which authorization flows we use, we need to make
> a difference between session timeouts.
>
>
>
>
>
>> I'm not particularly found of introducing so many settings on a client.
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt others
> would understand how and when to use them, and I think it can easily end up
> resulting in a lot of error cases.
>
>
>
> How about providing a checkbox which enables a one-to-one relationship
> between UserSessionModel and ClientSessionModel?
>
> Currently, UserSessionModel and ClientSessionModel are a one-to-many
> relationship, and this makes it difficult to set session timeout per client.
>
> If the checkbox enabled, not link a new ClientSessionModel to the existing
> UserSessionModel when a new client which uses the existing authentication
> result appeared but make a new UserSessionModel.
>
> If this possible, we don't need to change the way to manage sessions.
>
>
>
> Keycloak is a SSO solution and we have no plans on introducing per-client
> sessions.
>
>
>
>
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Friday, September 20, 2019 6:00 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
> client
>
>
>
> I'm still not quite following what you are trying to achieve.
>
>
>
> For authorization code flow it makes no sense at all to have different
> session timeouts as it is by definition a shared SSO session. Different
> security levels should be controlled things like step-up and authentication
> timeout, not by having different session timeouts. Further, I'm not sure if
> refresh token timeout should be configurable per-client here as end of the
> day a new refresh token can easily be obtained as long as the session is
> still active.
>
>
>
> For client credentials grant where the server obtains tokens this may make
> sense.
>
>
>
> I'm not particularly found of introducing so many settings on a client.
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt others
> would understand how and when to use them, and I think it can easily end up
> resulting in a lot of error cases.
>
>
>
> On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> Hello,
>
> In cloud-native application systems, there are various client applications
> and those applications are not the same level (i.e. security level,
> alliance level, development level). And generally, a realm manager or a
> resource server manager wants to set a different timeout to tokens (access
> token/refresh token) per client. For example, for a client which wants to
> minimize authentication considering usability, we set the timeout of a
> refresh token longer enough. For a client which wants to refresh tokens
> periodically to mitigate the token interception attack, we set the timeout
> of a refresh token according to the client requirement.
>
> Currently, the timeout of an access token can be overridden per client.
> However, the timeout of a refresh token (including offline token) cannot be
> overridden per client.
>
> We'd like to be able to override the timeout of a refresh token (including
> offline token) per client.
>
> We'd already tried to implement this just like access token lifespan
> overriding, and create JIRA ticket and PR, but Stian recommended that we
> should discuss this use case and how to implement in ML, so I opened this
> thread.
>
> For single sign-on purpose, it is useful to share sessions among clients
> in a realm.
> However, when we implement this, sessions are no longer shared among
> clients depending on the settings. And this is useful for API management
> purpose because, for API management purpose, tokens (= sessions) are
> associated with each client, and should be managed per client.
>
> What do you think about this feature? I would be very happy if you
> community gives any kind of comment on that.
>
> JIRA ticket is the following.
> https://issues.jboss.org/browse/KEYCLOAK-10907
>
<https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2...
>
> PR is the following.
> https://github.com/keycloak/keycloak/pull/6309
>
<https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2...
>
> Regards,
> Yoshiyuki Tabata
> Hitachi, Ltd.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
<https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2...
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:47 a.m.
Thanks for your comments and yes they make sense. I think we mostly have
the same opinion here.
What is achievable with Keycloak today puts a fair bit of the effort on the
application and the RP. Firstly the RP/API would need to be able to find
out how long since the user authenticated, which it can as that can be
added as a claim to the token. The RP can then reject request if it's to
long since the user authenticated. Further, the application (web/UI) would
need to use max_age and/or prompt=login to force the user to
re-authenticate.
Taking this one step further to step-up authentication which we plan to
introduce in the not to distant future. In this case the application can
use acr_values to request step-up. This also needs to most likely be
validated by the RP, which somehow needs to communicate this to the
applications.
Ideally Keycloak would have some support to make this easier and not have
to put all the burden on the app and the RP, but AFAIK there's no real
standard way of doing that. One idea is that we could somehow drive it
through client scopes. Let's say you have a client scope named
"high-risk-scope". Setting a max_age and also an acr value on the client
scope itself within Keycloak means that everytime an application requests a
token with that scope the refresh token timeout would be set accordingly
and the user would be required to authenticate at the appropriate level.
In summary though - this is something that needs to be thought through
properly. Right now I have too many things on my plate to start working on
any sort of design proposal around this, but if anyone from the community
would like to start working on something that would be great.
On Wed, 25 Sep 2019 at 23:17, Martin Maher <gentoo(a)penguindreams.us> wrote:
Stian:
In reading this thread and the OPs concerns, I see three components that
could exert or express control - the Keycloak server; the application
server; and the user.
From reading the OPs concerns, both in the original post and in the later
articulation, it seems as though there is a desire to have the user express
what is a high-risk API . . . "*Therefore end-user wants to
re-authenticate periodically*”, versus your example of the Application
server designating itself as a high-risk for all users.
I agree with your assertion that solving this issue through HTTP
session-timeouts would be problematic, not least of all for SSO type of
authentications.
Having the application server specify to the Keycloak server the
max-length of a valid authorization based upon successful authentication,
would permit the Keycloak server to set the “max-age” attribute, whereby
refresh tokens would no longer be issued or honored after that time,
leading to a requirement to reauthenticate.
The tricky bit for the OPs scenario is creating a method within the
application server for the user to express this to the application, which
could then be conveyed to Keycloak, which could then be set on the user
tokens.
This does lead back to the application server, as you asserted, but I
believe that there would need to be a mechanism, if one does not already
exist, for the application server to communicate this to Keycloak on a
per-user basis. It should also be possible for the Keycloak server to take
a configuration element that permits designation of high-risk and low-risk
APIs, in order to interfere with attempts to downgrade authentication
strengths for sensitive applications.
I hope this makes sense.
Regards,
Martin
On Sep 24, 2019, at 23:55 , Stian Thorgersen <sthorger(a)redhat.com> wrote:
I don't understand what's different with your use-case compared to what I
listed. As I understand it they are both pretty much the same use-case.
In either case different sessions and timeouts are not the correct
solution. Configurable refresh token timeout is probably not a good
solution either, at least not on its own without anything else.
On Wed, 25 Sep 2019 at 03:05, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
So trying to understand your use-case and simplifying things a bit. You
basically have two (or more) different groups of APIs. Let's call these
low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
don't need to authenticate regularly and a session can last for days (or
weeks). For high-risk APIs they need to authenticate more regularly.
This example is a little bit unfitted for our use case.
I give a concrete example.
For example, there are 2 client applications.
Client application A accesses high-risk APIs such as money transfer API.
Client application B accesses low-risk APIs such as balance inquiry API.
In client application A case, it's risky for an end-user to let the client
application to hold a valid refresh token long time because a risk
increases which an attacker sends money using the stolen mobile devices or
which an attacker steals the valid refresh token. Therefore end-user wants
to re-authenticate periodically and the client application guarantees to
end-user that it holds a valid refresh token only limited short time.
In client application B case, it's not risky for an end-user to let the
client application to hold a valid refresh token long time because it is
not much impact for end-user that an attacker checks end user's balance.
Therefore end-user does not want to re-authenticate periodically and the
client application holds a valid refresh token long time prioritizing
usability.
In the above use case, end-user does not trust client applications
completely, so it's meaningless that client application defines the
expiration of a refresh token. And it's meaningful that authorization
server (Keycloak) defines the expiration of a refresh token.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Tuesday, September 24, 2019 4:45 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan per
client
So trying to understand your use-case and simplifying things a bit. You
basically have two (or more) different groups of APIs. Let's call these
low-risk APIs and high-risk APIs. When a user invokes the low-risk API they
don't need to authenticate regularly and a session can last for days (or
weeks). For high-risk APIs they need to authenticate more regularly.
Now this is solved with looking at when the user last authenticated as
well as how the user was authenticated, not by having different session
timeouts. As we don't have step-up autentication support right now, that
leaves us with requiring users to re-authenticate more regularly for the
high-risk API.
Conceptually I can see at least two different ways to achieve the above:
1) Resource Server is responsible for verifying - the UI uses login=promt
and/or max_age to re-authenticate the user when needed. Further, the
resource server needs to check when user authenticate.
2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh
tokens with shorter duration for specific apps/UIs
Option 2 is problematic as the UI may just as well invoke both low-risk
and high-risk APIs. Further, in the future as we add step-up, high-risk may
be asking for step-up authentication, not re-authentication.
On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
Clients guarantee to end-users that clients access to end-users' resources
only within the expiration using the tokens. So end-users need to re-login
after the expiration and clients must not refresh tokens after the
expiration.
The expiration depends on each client by security reason, or usability
reason, or so on.
Therefore regardless of which authorization flows we use, we need to make
a difference between session timeouts.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship
between UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many
relationship, and this makes it difficult to set session timeout per
client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication
result appeared but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Keycloak is a SSO solution and we have no plans on introducing per-client
sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Friday, September 20, 2019 6:00 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session. Different
security levels should be controlled things like step-up and authentication
timeout, not by having different session timeouts. Further, I'm not sure if
refresh token timeout should be configurable per-client here as end of the
day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make
sense.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt others
would understand how and when to use them, and I think it can easily end up
resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Hello,
In cloud-native application systems, there are various client applications
and those applications are not the same level (i.e. security level,
alliance level, development level). And generally, a realm manager or a
resource server manager wants to set a different timeout to tokens (access
token/refresh token) per client. For example, for a client which wants to
minimize authentication considering usability, we set the timeout of a
refresh token longer enough. For a client which wants to refresh tokens
periodically to mitigate the token interception attack, we set the timeout
of a refresh token according to the client requirement.
Currently, the timeout of an access token can be overridden per client.
However, the timeout of a refresh token (including offline token) cannot be
overridden per client.
We'd like to be able to override the timeout of a refresh token (including
offline token) per client.
We'd already tried to implement this just like access token lifespan
overriding, and create JIRA ticket and PR, but Stian recommended that we
should discuss this use case and how to implement in ML, so I opened this
thread.
For single sign-on purpose, it is useful to share sessions among clients
in a realm.
However, when we implement this, sessions are no longer shared among
clients depending on the settings. And this is useful for API management
purpose because, for API management purpose, tokens (= sessions) are
associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you
community gives any kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907
<
https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2...
>
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
<
https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2...
>
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2...
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:43 a.m.
Instead of "Override Refresh token lifespan per client", I think that the
proposed idea tells
* Determine Refresh token lifespan per API (type).
* Which API (type) the RP can access can be conveyed as client scope value.
The simulated use case is as follows.
1. The refresh token's timeout value can be configurable by client scope value.
e.g.
scope = "high-risk-api" -> timeout = 1 day
scope = "low-risk-api" -> timeout = 30 day
2. When the refresh token expires due to its timeout value, its refresh token is no longer
effective.
e.g.
The RP had two refresh tokens, one got by scope = "high-risk-api", the other
got by scope = "low-risk-api". Both of them have different timeout value each
other.
After the "high-risk-api" refresh token is expired, if the RP sends
"high-risk-api" refresh token to keycloak in order to its token refresh,
keycloak rejects this token refresh request. The RP can prompt the user to re-authenticate
and re-consent on keycloak.
If the RP sends "low-risk-api" refresh token to keycloak in order to its token
refresh, keycloak returns the refreshed tokens.
Is my understanding correct?
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On
Behalf Of Stian Thorgersen
Sent: Friday, September 27, 2019 7:47 PM
To: Martin Maher <gentoo(a)penguindreams.us>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
Thanks for your comments and yes they make sense. I think we mostly have the same opinion
here.
What is achievable with Keycloak today puts a fair bit of the effort on the application
and the RP. Firstly the RP/API would need to be able to find out how long since the user
authenticated, which it can as that can be added as a claim to the token. The RP can then
reject request if it's to long since the user authenticated. Further, the application
(web/UI) would need to use max_age and/or prompt=login to force the user to
re-authenticate.
Taking this one step further to step-up authentication which we plan to introduce in the
not to distant future. In this case the application can use acr_values to request step-up.
This also needs to most likely be validated by the RP, which somehow needs to communicate
this to the applications.
Ideally Keycloak would have some support to make this easier and not have to put all the
burden on the app and the RP, but AFAIK there's no real standard way of doing that.
One idea is that we could somehow drive it through client scopes. Let's say you have a
client scope named "high-risk-scope". Setting a max_age and also an acr value on
the client scope itself within Keycloak means that everytime an application requests a
token with that scope the refresh token timeout would be set accordingly and the user
would be required to authenticate at the appropriate level.
In summary though - this is something that needs to be thought through properly. Right now
I have too many things on my plate to start working on any sort of design proposal around
this, but if anyone from the community would like to start working on something that would
be great.
On Wed, 25 Sep 2019 at 23:17, Martin Maher <gentoo(a)penguindreams.us> wrote:
Stian:
In reading this thread and the OPs concerns, I see three components
that could exert or express control - the Keycloak server; the
application server; and the user.
From reading the OPs concerns, both in the original post and in the
later articulation, it seems as though there is a desire to have the
user express what is a high-risk API . . . "*Therefore end-user wants
to re-authenticate periodically*”, versus your example of the
Application server designating itself as a high-risk for all users.
I agree with your assertion that solving this issue through HTTP
session-timeouts would be problematic, not least of all for SSO type
of authentications.
Having the application server specify to the Keycloak server the
max-length of a valid authorization based upon successful
authentication, would permit the Keycloak server to set the “max-age”
attribute, whereby refresh tokens would no longer be issued or honored
after that time, leading to a requirement to reauthenticate.
The tricky bit for the OPs scenario is creating a method within the
application server for the user to express this to the application,
which could then be conveyed to Keycloak, which could then be set on
the user tokens.
This does lead back to the application server, as you asserted, but I
believe that there would need to be a mechanism, if one does not
already exist, for the application server to communicate this to
Keycloak on a per-user basis. It should also be possible for the
Keycloak server to take a configuration element that permits
designation of high-risk and low-risk APIs, in order to interfere with
attempts to downgrade authentication strengths for sensitive applications.
I hope this makes sense.
Regards,
Martin
On Sep 24, 2019, at 23:55 , Stian Thorgersen <sthorger(a)redhat.com> wrote:
I don't understand what's different with your use-case compared to
what I listed. As I understand it they are both pretty much the same use-case.
In either case different sessions and timeouts are not the correct
solution. Configurable refresh token timeout is probably not a good
solution either, at least not on its own without anything else.
On Wed, 25 Sep 2019 at 03:05, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
So trying to understand your use-case and simplifying things a bit.
You
basically have two (or more) different groups of APIs. Let's call
these low-risk APIs and high-risk APIs. When a user invokes the
low-risk API they don't need to authenticate regularly and a session
can last for days (or weeks). For high-risk APIs they need to authenticate more
regularly.
This example is a little bit unfitted for our use case.
I give a concrete example.
For example, there are 2 client applications.
Client application A accesses high-risk APIs such as money transfer API.
Client application B accesses low-risk APIs such as balance inquiry API.
In client application A case, it's risky for an end-user to let the
client application to hold a valid refresh token long time because a
risk increases which an attacker sends money using the stolen mobile
devices or which an attacker steals the valid refresh token. Therefore
end-user wants to re-authenticate periodically and the client
application guarantees to end-user that it holds a valid refresh token only limited short
time.
In client application B case, it's not risky for an end-user to let
the client application to hold a valid refresh token long time because
it is not much impact for end-user that an attacker checks end user's balance.
Therefore end-user does not want to re-authenticate periodically and
the client application holds a valid refresh token long time
prioritizing usability.
In the above use case, end-user does not trust client applications
completely, so it's meaningless that client application defines the
expiration of a refresh token. And it's meaningful that authorization
server (Keycloak) defines the expiration of a refresh token.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Tuesday, September 24, 2019 4:45 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan
per client
So trying to understand your use-case and simplifying things a bit.
You basically have two (or more) different groups of APIs. Let's call
these low-risk APIs and high-risk APIs. When a user invokes the
low-risk API they don't need to authenticate regularly and a session
can last for days (or weeks). For high-risk APIs they need to authenticate more
regularly.
Now this is solved with looking at when the user last authenticated as
well as how the user was authenticated, not by having different
session timeouts. As we don't have step-up autentication support right
now, that leaves us with requiring users to re-authenticate more
regularly for the high-risk API.
Conceptually I can see at least two different ways to achieve the above:
1) Resource Server is responsible for verifying - the UI uses
login=promt and/or max_age to re-authenticate the user when needed.
Further, the resource server needs to check when user authenticate.
2) Keycloak is responsible for verifying - perhaps Keycloak issues
refresh tokens with shorter duration for specific apps/UIs
Option 2 is problematic as the UI may just as well invoke both
low-risk and high-risk APIs. Further, in the future as we add step-up,
high-risk may be asking for step-up authentication, not re-authentication.
On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session.
Different security levels should be controlled things like step-up and
authentication timeout, not by having different session timeouts.
Further, I'm not sure if refresh token timeout should be configurable
per-client here as end of the day a new refresh token can easily be
obtained as long as the session is still active.
Clients guarantee to end-users that clients access to end-users'
resources only within the expiration using the tokens. So end-users
need to re-login after the expiration and clients must not refresh
tokens after the expiration.
The expiration depends on each client by security reason, or usability
reason, or so on.
Therefore regardless of which authorization flows we use, we need to
make a difference between session timeouts.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt
others would understand how and when to use them, and I think it can
easily end up resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship
between UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many
relationship, and this makes it difficult to set session timeout per
client.
If the checkbox enabled, not link a new ClientSessionModel to the
existing UserSessionModel when a new client which uses the existing
authentication result appeared but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Keycloak is a SSO solution and we have no plans on introducing
per-client sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*Sent:* Friday, September 20, 2019 6:00 PM
*To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different
session timeouts as it is by definition a shared SSO session.
Different security levels should be controlled things like step-up and
authentication timeout, not by having different session timeouts.
Further, I'm not sure if refresh token timeout should be configurable
per-client here as end of the day a new refresh token can easily be
obtained as long as the session is still active.
For client credentials grant where the server obtains tokens this may
make sense.
I'm not particularly found of introducing so many settings on a client.
It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply
adding all these settings on a client may work for you, but I doubt
others would understand how and when to use them, and I think it can
easily end up resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Hello,
In cloud-native application systems, there are various client
applications and those applications are not the same level (i.e.
security level, alliance level, development level). And generally, a
realm manager or a resource server manager wants to set a different
timeout to tokens (access token/refresh token) per client. For
example, for a client which wants to minimize authentication
considering usability, we set the timeout of a refresh token longer
enough. For a client which wants to refresh tokens periodically to
mitigate the token interception attack, we set the timeout of a refresh token according
to the client requirement.
Currently, the timeout of an access token can be overridden per client.
However, the timeout of a refresh token (including offline token)
cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token
(including offline token) per client.
We'd already tried to implement this just like access token lifespan
overriding, and create JIRA ticket and PR, but Stian recommended that
we should discuss this use case and how to implement in ML, so I
opened this thread.
For single sign-on purpose, it is useful to share sessions among
clients in a realm.
However, when we implement this, sessions are no longer shared among
clients depending on the settings. And this is useful for API
management purpose because, for API management purpose, tokens (=
sessions) are associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you
community gives any kind of comment on that.
JIRA ticket is the following.
https://clicktime.symantec.com/3T38NcSH1Vc12vciukE8Hxv7Vc?u=https%3A%2
F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
<
https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2
F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
>
PR is the following.
https://clicktime.symantec.com/3NZ9Bwcut6QLNg5aMQgjbta7Vc?u=https%3A%2
F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
<
https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2
F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
>
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
<
https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2
F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2F%2...
9:11 a.m.
I'm not sure if the scope is suitable to address the use case you
are referring to. Instead, I think we could consider using resource
indicators [1] so that policies that rule the token response (or even the
authorization response) are based on the resource you are trying to access.
Scopes will continue providing coarse-grained access control, only.
By "high|low-risk-api", it seems you are actually indicating the API you
want to access and not really the scope of access.
[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08
On Mon, Sep 30, 2019 at 5:46 AM 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Instead of "Override Refresh token lifespan per client", I
think that the
proposed idea tells
* Determine Refresh token lifespan per API (type).
* Which API (type) the RP can access can be conveyed as client scope
value.
The simulated use case is as follows.
1. The refresh token's timeout value can be configurable by client scope
value.
e.g.
scope = "high-risk-api" -> timeout = 1 day
scope = "low-risk-api" -> timeout = 30 day
2. When the refresh token expires due to its timeout value, its refresh
token is no longer effective.
e.g.
The RP had two refresh tokens, one got by scope = "high-risk-api", the
other got by scope = "low-risk-api". Both of them have different timeout
value each other.
After the "high-risk-api" refresh token is expired, if the RP sends
"high-risk-api" refresh token to keycloak in order to its token refresh,
keycloak rejects this token refresh request. The RP can prompt the user to
re-authenticate and re-consent on keycloak.
If the RP sends "low-risk-api" refresh token to keycloak in order to its
token refresh, keycloak returns the refreshed tokens.
Is my understanding correct?
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Friday, September 27, 2019 7:47 PM
To: Martin Maher <gentoo(a)penguindreams.us>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
Thanks for your comments and yes they make sense. I think we mostly have
the same opinion here.
What is achievable with Keycloak today puts a fair bit of the effort on
the application and the RP. Firstly the RP/API would need to be able to
find out how long since the user authenticated, which it can as that can be
added as a claim to the token. The RP can then reject request if it's to
long since the user authenticated. Further, the application (web/UI) would
need to use max_age and/or prompt=login to force the user to
re-authenticate.
Taking this one step further to step-up authentication which we plan to
introduce in the not to distant future. In this case the application can
use acr_values to request step-up. This also needs to most likely be
validated by the RP, which somehow needs to communicate this to the
applications.
Ideally Keycloak would have some support to make this easier and not have
to put all the burden on the app and the RP, but AFAIK there's no real
standard way of doing that. One idea is that we could somehow drive it
through client scopes. Let's say you have a client scope named
"high-risk-scope". Setting a max_age and also an acr value on the client
scope itself within Keycloak means that everytime an application requests a
token with that scope the refresh token timeout would be set accordingly
and the user would be required to authenticate at the appropriate level.
In summary though - this is something that needs to be thought through
properly. Right now I have too many things on my plate to start working on
any sort of design proposal around this, but if anyone from the community
would like to start working on something that would be great.
On Wed, 25 Sep 2019 at 23:17, Martin Maher <gentoo(a)penguindreams.us>
wrote:
> Stian:
>
> In reading this thread and the OPs concerns, I see three components
> that could exert or express control - the Keycloak server; the
> application server; and the user.
>
> From reading the OPs concerns, both in the original post and in the
> later articulation, it seems as though there is a desire to have the
> user express what is a high-risk API . . . "*Therefore end-user wants
> to re-authenticate periodically*”, versus your example of the
> Application server designating itself as a high-risk for all users.
>
> I agree with your assertion that solving this issue through HTTP
> session-timeouts would be problematic, not least of all for SSO type
> of authentications.
>
> Having the application server specify to the Keycloak server the
> max-length of a valid authorization based upon successful
> authentication, would permit the Keycloak server to set the “max-age”
> attribute, whereby refresh tokens would no longer be issued or honored
> after that time, leading to a requirement to reauthenticate.
>
> The tricky bit for the OPs scenario is creating a method within the
> application server for the user to express this to the application,
> which could then be conveyed to Keycloak, which could then be set on
> the user tokens.
>
> This does lead back to the application server, as you asserted, but I
> believe that there would need to be a mechanism, if one does not
> already exist, for the application server to communicate this to
> Keycloak on a per-user basis. It should also be possible for the
> Keycloak server to take a configuration element that permits
> designation of high-risk and low-risk APIs, in order to interfere with
> attempts to downgrade authentication strengths for sensitive
applications.
>
> I hope this makes sense.
>
> Regards,
>
> Martin
>
> On Sep 24, 2019, at 23:55 , Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
> I don't understand what's different with your use-case compared to
> what I listed. As I understand it they are both pretty much the same
use-case.
>
> In either case different sessions and timeouts are not the correct
> solution. Configurable refresh token timeout is probably not a good
> solution either, at least not on its own without anything else.
>
> On Wed, 25 Sep 2019 at 03:05, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> So trying to understand your use-case and simplifying things a bit.
> You
>
> basically have two (or more) different groups of APIs. Let's call
> these low-risk APIs and high-risk APIs. When a user invokes the
> low-risk API they don't need to authenticate regularly and a session
> can last for days (or weeks). For high-risk APIs they need to
authenticate more regularly.
>
>
>
> This example is a little bit unfitted for our use case.
>
> I give a concrete example.
>
>
>
> For example, there are 2 client applications.
>
> Client application A accesses high-risk APIs such as money transfer API.
>
> Client application B accesses low-risk APIs such as balance inquiry API.
>
>
>
> In client application A case, it's risky for an end-user to let the
> client application to hold a valid refresh token long time because a
> risk increases which an attacker sends money using the stolen mobile
> devices or which an attacker steals the valid refresh token. Therefore
> end-user wants to re-authenticate periodically and the client
> application guarantees to end-user that it holds a valid refresh token
only limited short time.
>
>
>
> In client application B case, it's not risky for an end-user to let
> the client application to hold a valid refresh token long time because
> it is not much impact for end-user that an attacker checks end user's
balance.
> Therefore end-user does not want to re-authenticate periodically and
> the client application holds a valid refresh token long time
> prioritizing usability.
>
>
>
> In the above use case, end-user does not trust client applications
> completely, so it's meaningless that client application defines the
> expiration of a refresh token. And it's meaningful that authorization
> server (Keycloak) defines the expiration of a refresh token.
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Tuesday, September 24, 2019 4:45 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan
> per client
>
>
>
> So trying to understand your use-case and simplifying things a bit.
> You basically have two (or more) different groups of APIs. Let's call
> these low-risk APIs and high-risk APIs. When a user invokes the
> low-risk API they don't need to authenticate regularly and a session
> can last for days (or weeks). For high-risk APIs they need to
authenticate more regularly.
>
>
>
> Now this is solved with looking at when the user last authenticated as
> well as how the user was authenticated, not by having different
> session timeouts. As we don't have step-up autentication support right
> now, that leaves us with requiring users to re-authenticate more
> regularly for the high-risk API.
>
>
>
> Conceptually I can see at least two different ways to achieve the above:
>
>
>
> 1) Resource Server is responsible for verifying - the UI uses
> login=promt and/or max_age to re-authenticate the user when needed.
> Further, the resource server needs to check when user authenticate.
>
> 2) Keycloak is responsible for verifying - perhaps Keycloak issues
> refresh tokens with shorter duration for specific apps/UIs
>
>
>
> Option 2 is problematic as the UI may just as well invoke both
> low-risk and high-risk APIs. Further, in the future as we add step-up,
> high-risk may be asking for step-up authentication, not
re-authentication.
>
>
>
> On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> For authorization code flow it makes no sense at all to have different
>
> session timeouts as it is by definition a shared SSO session.
> Different security levels should be controlled things like step-up and
> authentication timeout, not by having different session timeouts.
> Further, I'm not sure if refresh token timeout should be configurable
> per-client here as end of the day a new refresh token can easily be
> obtained as long as the session is still active.
>
>
>
> Clients guarantee to end-users that clients access to end-users'
> resources only within the expiration using the tokens. So end-users
> need to re-login after the expiration and clients must not refresh
> tokens after the expiration.
>
> The expiration depends on each client by security reason, or usability
> reason, or so on.
>
> Therefore regardless of which authorization flows we use, we need to
> make a difference between session timeouts.
>
>
>
>
>
> I'm not particularly found of introducing so many settings on a client.
>
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt
> others would understand how and when to use them, and I think it can
> easily end up resulting in a lot of error cases.
>
>
>
> How about providing a checkbox which enables a one-to-one relationship
> between UserSessionModel and ClientSessionModel?
>
> Currently, UserSessionModel and ClientSessionModel are a one-to-many
> relationship, and this makes it difficult to set session timeout per
> client.
>
> If the checkbox enabled, not link a new ClientSessionModel to the
> existing UserSessionModel when a new client which uses the existing
> authentication result appeared but make a new UserSessionModel.
>
> If this possible, we don't need to change the way to manage sessions.
>
>
>
> Keycloak is a SSO solution and we have no plans on introducing
> per-client sessions.
>
>
>
>
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Friday, September 20, 2019 6:00 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
> client
>
>
>
> I'm still not quite following what you are trying to achieve.
>
>
>
> For authorization code flow it makes no sense at all to have different
> session timeouts as it is by definition a shared SSO session.
> Different security levels should be controlled things like step-up and
> authentication timeout, not by having different session timeouts.
> Further, I'm not sure if refresh token timeout should be configurable
> per-client here as end of the day a new refresh token can easily be
> obtained as long as the session is still active.
>
>
>
> For client credentials grant where the server obtains tokens this may
> make sense.
>
>
>
> I'm not particularly found of introducing so many settings on a client.
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt
> others would understand how and when to use them, and I think it can
> easily end up resulting in a lot of error cases.
>
>
>
> On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> Hello,
>
> In cloud-native application systems, there are various client
> applications and those applications are not the same level (i.e.
> security level, alliance level, development level). And generally, a
> realm manager or a resource server manager wants to set a different
> timeout to tokens (access token/refresh token) per client. For
> example, for a client which wants to minimize authentication
> considering usability, we set the timeout of a refresh token longer
> enough. For a client which wants to refresh tokens periodically to
> mitigate the token interception attack, we set the timeout of a refresh
token according to the client requirement.
>
> Currently, the timeout of an access token can be overridden per client.
> However, the timeout of a refresh token (including offline token)
> cannot be overridden per client.
>
> We'd like to be able to override the timeout of a refresh token
> (including offline token) per client.
>
> We'd already tried to implement this just like access token lifespan
> overriding, and create JIRA ticket and PR, but Stian recommended that
> we should discuss this use case and how to implement in ML, so I
> opened this thread.
>
> For single sign-on purpose, it is useful to share sessions among
> clients in a realm.
> However, when we implement this, sessions are no longer shared among
> clients depending on the settings. And this is useful for API
> management purpose because, for API management purpose, tokens (=
> sessions) are associated with each client, and should be managed per
client.
>
> What do you think about this feature? I would be very happy if you
> community gives any kind of comment on that.
>
> JIRA ticket is the following.
> https://clicktime.symantec.com/3T38NcSH1Vc12vciukE8Hxv7Vc?u=https%3A%2
> F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
> <
> https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2
> F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
> >
>
> PR is the following.
> https://clicktime.symantec.com/3NZ9Bwcut6QLNg5aMQgjbta7Vc?u=https%3A%2
> F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
> <
> https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2
> F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
> >
>
> Regards,
> Yoshiyuki Tabata
> Hitachi, Ltd.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> <
> https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> >
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2F%2...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:38 a.m.
On Mon, 30 Sep 2019 at 10:44, 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy(a)hitachi.com> wrote:
Instead of "Override Refresh token lifespan per client", I
think that the
proposed idea tells
* Determine Refresh token lifespan per API (type).
* Which API (type) the RP can access can be conveyed as client scope
value.
The simulated use case is as follows.
1. The refresh token's timeout value can be configurable by client scope
value.
e.g.
scope = "high-risk-api" -> timeout = 1 day
scope = "low-risk-api" -> timeout = 30 day
Yes, but the I would argue the configuration option on the client scope
should be about auth requirements, not token timeouts. So should be "max
authentication age", rather than "refresh token timeout".
2. When the refresh token expires due to its timeout value, its refresh
token is no longer effective.
e.g.
The RP had two refresh tokens, one got by scope = "high-risk-api", the
other got by scope = "low-risk-api". Both of them have different timeout
value each other.
After the "high-risk-api" refresh token is expired, if the RP sends
"high-risk-api" refresh token to keycloak in order to its token refresh,
keycloak rejects this token refresh request. The RP can prompt the user to
re-authenticate and re-consent on keycloak.
If the RP sends "low-risk-api" refresh token to keycloak in order to its
token refresh, keycloak returns the refreshed tokens.
Yes, but would also allow a single token with both scopes, where the token
timeout would be set according to the lowest auth max age
Is my understanding correct?
Yes - but, bear in mind that my idea here is more of a brain-dump rather
than something that has been fully thought out ;)
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Friday, September 27, 2019 7:47 PM
To: Martin Maher <gentoo(a)penguindreams.us>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
Thanks for your comments and yes they make sense. I think we mostly have
the same opinion here.
What is achievable with Keycloak today puts a fair bit of the effort on
the application and the RP. Firstly the RP/API would need to be able to
find out how long since the user authenticated, which it can as that can be
added as a claim to the token. The RP can then reject request if it's to
long since the user authenticated. Further, the application (web/UI) would
need to use max_age and/or prompt=login to force the user to
re-authenticate.
Taking this one step further to step-up authentication which we plan to
introduce in the not to distant future. In this case the application can
use acr_values to request step-up. This also needs to most likely be
validated by the RP, which somehow needs to communicate this to the
applications.
Ideally Keycloak would have some support to make this easier and not have
to put all the burden on the app and the RP, but AFAIK there's no real
standard way of doing that. One idea is that we could somehow drive it
through client scopes. Let's say you have a client scope named
"high-risk-scope". Setting a max_age and also an acr value on the client
scope itself within Keycloak means that everytime an application requests a
token with that scope the refresh token timeout would be set accordingly
and the user would be required to authenticate at the appropriate level.
In summary though - this is something that needs to be thought through
properly. Right now I have too many things on my plate to start working on
any sort of design proposal around this, but if anyone from the community
would like to start working on something that would be great.
On Wed, 25 Sep 2019 at 23:17, Martin Maher <gentoo(a)penguindreams.us>
wrote:
> Stian:
>
> In reading this thread and the OPs concerns, I see three components
> that could exert or express control - the Keycloak server; the
> application server; and the user.
>
> From reading the OPs concerns, both in the original post and in the
> later articulation, it seems as though there is a desire to have the
> user express what is a high-risk API . . . "*Therefore end-user wants
> to re-authenticate periodically*”, versus your example of the
> Application server designating itself as a high-risk for all users.
>
> I agree with your assertion that solving this issue through HTTP
> session-timeouts would be problematic, not least of all for SSO type
> of authentications.
>
> Having the application server specify to the Keycloak server the
> max-length of a valid authorization based upon successful
> authentication, would permit the Keycloak server to set the “max-age”
> attribute, whereby refresh tokens would no longer be issued or honored
> after that time, leading to a requirement to reauthenticate.
>
> The tricky bit for the OPs scenario is creating a method within the
> application server for the user to express this to the application,
> which could then be conveyed to Keycloak, which could then be set on
> the user tokens.
>
> This does lead back to the application server, as you asserted, but I
> believe that there would need to be a mechanism, if one does not
> already exist, for the application server to communicate this to
> Keycloak on a per-user basis. It should also be possible for the
> Keycloak server to take a configuration element that permits
> designation of high-risk and low-risk APIs, in order to interfere with
> attempts to downgrade authentication strengths for sensitive
applications.
>
> I hope this makes sense.
>
> Regards,
>
> Martin
>
> On Sep 24, 2019, at 23:55 , Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
> I don't understand what's different with your use-case compared to
> what I listed. As I understand it they are both pretty much the same
use-case.
>
> In either case different sessions and timeouts are not the correct
> solution. Configurable refresh token timeout is probably not a good
> solution either, at least not on its own without anything else.
>
> On Wed, 25 Sep 2019 at 03:05, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> So trying to understand your use-case and simplifying things a bit.
> You
>
> basically have two (or more) different groups of APIs. Let's call
> these low-risk APIs and high-risk APIs. When a user invokes the
> low-risk API they don't need to authenticate regularly and a session
> can last for days (or weeks). For high-risk APIs they need to
authenticate more regularly.
>
>
>
> This example is a little bit unfitted for our use case.
>
> I give a concrete example.
>
>
>
> For example, there are 2 client applications.
>
> Client application A accesses high-risk APIs such as money transfer API.
>
> Client application B accesses low-risk APIs such as balance inquiry API.
>
>
>
> In client application A case, it's risky for an end-user to let the
> client application to hold a valid refresh token long time because a
> risk increases which an attacker sends money using the stolen mobile
> devices or which an attacker steals the valid refresh token. Therefore
> end-user wants to re-authenticate periodically and the client
> application guarantees to end-user that it holds a valid refresh token
only limited short time.
>
>
>
> In client application B case, it's not risky for an end-user to let
> the client application to hold a valid refresh token long time because
> it is not much impact for end-user that an attacker checks end user's
balance.
> Therefore end-user does not want to re-authenticate periodically and
> the client application holds a valid refresh token long time
> prioritizing usability.
>
>
>
> In the above use case, end-user does not trust client applications
> completely, so it's meaningless that client application defines the
> expiration of a refresh token. And it's meaningful that authorization
> server (Keycloak) defines the expiration of a refresh token.
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Tuesday, September 24, 2019 4:45 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan
> per client
>
>
>
> So trying to understand your use-case and simplifying things a bit.
> You basically have two (or more) different groups of APIs. Let's call
> these low-risk APIs and high-risk APIs. When a user invokes the
> low-risk API they don't need to authenticate regularly and a session
> can last for days (or weeks). For high-risk APIs they need to
authenticate more regularly.
>
>
>
> Now this is solved with looking at when the user last authenticated as
> well as how the user was authenticated, not by having different
> session timeouts. As we don't have step-up autentication support right
> now, that leaves us with requiring users to re-authenticate more
> regularly for the high-risk API.
>
>
>
> Conceptually I can see at least two different ways to achieve the above:
>
>
>
> 1) Resource Server is responsible for verifying - the UI uses
> login=promt and/or max_age to re-authenticate the user when needed.
> Further, the resource server needs to check when user authenticate.
>
> 2) Keycloak is responsible for verifying - perhaps Keycloak issues
> refresh tokens with shorter duration for specific apps/UIs
>
>
>
> Option 2 is problematic as the UI may just as well invoke both
> low-risk and high-risk APIs. Further, in the future as we add step-up,
> high-risk may be asking for step-up authentication, not
re-authentication.
>
>
>
> On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> For authorization code flow it makes no sense at all to have different
>
> session timeouts as it is by definition a shared SSO session.
> Different security levels should be controlled things like step-up and
> authentication timeout, not by having different session timeouts.
> Further, I'm not sure if refresh token timeout should be configurable
> per-client here as end of the day a new refresh token can easily be
> obtained as long as the session is still active.
>
>
>
> Clients guarantee to end-users that clients access to end-users'
> resources only within the expiration using the tokens. So end-users
> need to re-login after the expiration and clients must not refresh
> tokens after the expiration.
>
> The expiration depends on each client by security reason, or usability
> reason, or so on.
>
> Therefore regardless of which authorization flows we use, we need to
> make a difference between session timeouts.
>
>
>
>
>
> I'm not particularly found of introducing so many settings on a client.
>
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt
> others would understand how and when to use them, and I think it can
> easily end up resulting in a lot of error cases.
>
>
>
> How about providing a checkbox which enables a one-to-one relationship
> between UserSessionModel and ClientSessionModel?
>
> Currently, UserSessionModel and ClientSessionModel are a one-to-many
> relationship, and this makes it difficult to set session timeout per
> client.
>
> If the checkbox enabled, not link a new ClientSessionModel to the
> existing UserSessionModel when a new client which uses the existing
> authentication result appeared but make a new UserSessionModel.
>
> If this possible, we don't need to change the way to manage sessions.
>
>
>
> Keycloak is a SSO solution and we have no plans on introducing
> per-client sessions.
>
>
>
>
>
>
>
> Regards,
>
> Yoshiyuki Tabata
>
> Hitachi, Ltd.
>
>
>
> *From:* Stian Thorgersen <sthorger(a)redhat.com>
> *Sent:* Friday, September 20, 2019 6:00 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* [!]Re: [keycloak-dev] Override Refresh token lifespan per
> client
>
>
>
> I'm still not quite following what you are trying to achieve.
>
>
>
> For authorization code flow it makes no sense at all to have different
> session timeouts as it is by definition a shared SSO session.
> Different security levels should be controlled things like step-up and
> authentication timeout, not by having different session timeouts.
> Further, I'm not sure if refresh token timeout should be configurable
> per-client here as end of the day a new refresh token can easily be
> obtained as long as the session is still active.
>
>
>
> For client credentials grant where the server obtains tokens this may
> make sense.
>
>
>
> I'm not particularly found of introducing so many settings on a client.
> It's difficult to setup and error prone. So this use-case needs to be
> described properly and we need to find a decent solution to it. Simply
> adding all these settings on a client may work for you, but I doubt
> others would understand how and when to use them, and I think it can
> easily end up resulting in a lot of error cases.
>
>
>
> On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI <
> yoshiyuki.tabata.jy(a)hitachi.com> wrote:
>
> Hello,
>
> In cloud-native application systems, there are various client
> applications and those applications are not the same level (i.e.
> security level, alliance level, development level). And generally, a
> realm manager or a resource server manager wants to set a different
> timeout to tokens (access token/refresh token) per client. For
> example, for a client which wants to minimize authentication
> considering usability, we set the timeout of a refresh token longer
> enough. For a client which wants to refresh tokens periodically to
> mitigate the token interception attack, we set the timeout of a refresh
token according to the client requirement.
>
> Currently, the timeout of an access token can be overridden per client.
> However, the timeout of a refresh token (including offline token)
> cannot be overridden per client.
>
> We'd like to be able to override the timeout of a refresh token
> (including offline token) per client.
>
> We'd already tried to implement this just like access token lifespan
> overriding, and create JIRA ticket and PR, but Stian recommended that
> we should discuss this use case and how to implement in ML, so I
> opened this thread.
>
> For single sign-on purpose, it is useful to share sessions among
> clients in a realm.
> However, when we implement this, sessions are no longer shared among
> clients depending on the settings. And this is useful for API
> management purpose because, for API management purpose, tokens (=
> sessions) are associated with each client, and should be managed per
client.
>
> What do you think about this feature? I would be very happy if you
> community gives any kind of comment on that.
>
> JIRA ticket is the following.
> https://clicktime.symantec.com/3T38NcSH1Vc12vciukE8Hxv7Vc?u=https%3A%2
> F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
> <
> https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2
> F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907
> >
>
> PR is the following.
> https://clicktime.symantec.com/3NZ9Bwcut6QLNg5aMQgjbta7Vc?u=https%3A%2
> F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
> <
> https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2
> F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309
> >
>
> Regards,
> Yoshiyuki Tabata
> Hitachi, Ltd.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> <
> https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> >
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2F%2...
1913
days inactive
1924
days old
10 comments
4 participants
participants (4)
-
Martin Maher -
Pedro Igor Silva -
Stian Thorgersen -
田畑義之 / TABATA，YOSHIYUKI