8:37 a.m.
All,
When an user's session is timed out, the usual approach is to issue a
logout via the JavaScript adapter, which in turn will redirect the
browser to the login page at Keycloak.
The problem we are facing is that the user might not be active at this
time (the session has already timed out, after all), so, it might take a
while for the user to login again. If the user takes too long to login
again, Keycloak will display a login error, saying "Login timeout.
Please login again".
While I understand the technical aspects behind this, I think this is
problematic from the UXD perspective. Why should the user enter the same
valid login/password again, if the first ones were just fine?
As a "temporary" solution for Hawkular, we are *not* issuing a logout
via the JS adapter, but doing a "clearToken" and showing a modal with a
message like "Your session has timed out, login again", forcing the user
to click on a "Login" button, which will then redirect the user to the
login page. This is also not optimal from the UXD perspective, but at
least won't display an error message to the user.
As we can't possibly be the only ones with this (minor) problem, I'm
wondering if a set of redirects "in the background" couldn't solve the
technical issues, while keeping the login process "error free" from the
user's perspective. Or if we should indeed handle this situation on our
side.
For reference: https://issues.jboss.org/browse/HAWKULAR-444
- Juca.
5:07 p.m.
On 7/15/2015 9:37 AM, Juraci Paixão Kröhling wrote:
All,
When an user's session is timed out, the usual approach is to issue a
logout via the JavaScript adapter, which in turn will redirect the
browser to the login page at Keycloak.
The problem we are facing is that the user might not be active at this
time (the session has already timed out, after all), so, it might take a
while for the user to login again. If the user takes too long to login
again, Keycloak will display a login error, saying "Login timeout.
Please login again".
Yeah, we are fixing timeouts a little. There are 2 timeouts: Timeout
of a login action. This happens if you take too long in the login
process. In this case the login session is still active in memory.
What we'll do is just redirect the user to the login screen to start
over and give them this error message. "You took too long to login.
Please restart login process.".
Next one is timeout of the session. When this happens, we have no
information on how to complete the login. Information like the SAML
Request or OIDC query parameters. In this case we will be redirecting
back to the client. Client will choose whether to restart
authentication over or not.
While I understand the technical aspects behind this, I think this
is
problematic from the UXD perspective. Why should the user enter the same
valid login/password again, if the first ones were just fine?
I'm not sure we can fix this. If there is a session timeout, we have no
information on how to complete the authentication as this information
has been wiped out. So the only option is to redirect back to the
client in this situation.
As a "temporary" solution for Hawkular, we are *not*
issuing a logout
via the JS adapter, but doing a "clearToken" and showing a modal with a
message like "Your session has timed out, login again", forcing the user
to click on a "Login" button, which will then redirect the user to the
login page. This is also not optimal from the UXD perspective, but at
least won't display an error message to the user.
I think what you are doing is the best solution.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:04 a.m.
Bill,
Thanks for your answer. While I understand what happens in the
background, I still have some concerns about the user experience of this
process. More inline.
On 07/16/2015 12:07 AM, Bill Burke wrote:
Yeah, we are fixing timeouts a little. There are 2 timeouts:
Timeout
of a login action. This happens if you take too long in the login
process. In this case the login session is still active in memory.
What we'll do is just redirect the user to the login screen to start
over and give them this error message. "You took too long to login.
Please restart login process.".
For this timeout, I don't see a reason why it can't just start a fresh
login session and perform the login with the provided credentials. I'm
with the basic scenario in mind, and I realize that this might not
*always* be possible, but the server should know which scenarios are
possible and which aren't, right? From the user's perspective, I can't
understand why my credentials weren't accepted on the first time, but
accepted on the second time, a couple of seconds later.
Next one is timeout of the session. When this happens, we have no
information on how to complete the login. Information like the SAML
Request or OIDC query parameters. In this case we will be redirecting
back to the client. Client will choose whether to restart
authentication over or not.
This seems trickier, but similar to the above: the server knows (based
on the realm) if just starting a new session is enough, no?
I'm not sure we can fix this. If there is a session timeout, we
have no
information on how to complete the authentication as this information
has been wiped out. So the only option is to redirect back to the
client in this situation.
Actually, the user is *not* redirected back to the original application.
Entering the login/password again will just do the right thing: the user
will be logged in, and then redirected back to the original application.
- Juca.
11:41 a.m.
On 7/16/2015 11:04 AM, Juraci Paixão Kröhling wrote:
Bill,
Thanks for your answer. While I understand what happens in the
background, I still have some concerns about the user experience of this
process. More inline.
On 07/16/2015 12:07 AM, Bill Burke wrote:
> Yeah, we are fixing timeouts a little. There are 2 timeouts: Timeout
> of a login action. This happens if you take too long in the login
> process. In this case the login session is still active in memory.
> What we'll do is just redirect the user to the login screen to start
> over and give them this error message. "You took too long to login.
> Please restart login process.".
For this timeout, I don't see a reason why it can't just start a fresh
login session and perform the login with the provided credentials. I'm
with the basic scenario in mind, and I realize that this might not
*always* be possible, but the server should know which scenarios are
possible and which aren't, right? From the user's perspective, I can't
understand why my credentials weren't accepted on the first time, but
accepted on the second time, a couple of seconds later.
Honestly you're just going to have to deal with it. If you don't like
this timeout, then just set it to be the same as the session timeout and
you will never see this message.
It works the way it works because keycloak is making sure you are not
trying to hack and skip around the authentication flow. Even though the
username/password screen may be the first thing the user sees, there's
other optional non-browser authenticators that could have run: i.e.
kerberos. Kerberos requires one or more challenge/response messages
with the browser. The authentication implementation would become just
way too complex to support this edge case.
> Next one is timeout of the session. When this happens, we have
no
> information on how to complete the login. Information like the SAML
> Request or OIDC query parameters. In this case we will be redirecting
> back to the client. Client will choose whether to restart
> authentication over or not.
This seems trickier, but similar to the above: the server knows (based
on the realm) if just starting a new session is enough, no?
If the server session times out, it is removed. Information that is
needed to complete authentication with the client is completely gone
(i.e. information in the original SAML Request (session ids from the
client, relay state, callback url, name-id format). Redirect URI and
state parameters for OIDC). The session also keeps track of the state
of the authentication flow. For example, login could be a multi-step
process:
1. client-cert validation
2. username/password
3. OTP
You could be on step #3 when the server session times out. I'm sorry,
but there is no avoiding starting over authentication in this scenario.
I could look to store some of the initial request metadata in a cookie
to avoid having to redirect back to client. But I'm worried that the
info might be too large. I'm also worried about the security
implications of a cookie like this because SAML Requests can be signed
and verified. Stale cookies might create sneaky vulnerabilities, etc...
> I'm not sure we can fix this. If there is a session timeout,
we have no
> information on how to complete the authentication as this information
> has been wiped out. So the only option is to redirect back to the
> client in this situation.
Actually, the user is *not* redirected back to the original application.
Entering the login/password again will just do the right thing: the user
will be logged in, and then redirected back to the original application.
Right now, there is an error screen message when this happens. We are
fixing this so that the clientId is stored in the session code so that
there can be a link "back to application".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3452
days inactive
3453
days old
3 comments
2 participants
participants (2)
-
Bill Burke -
Juraci Paixão Kröhling