[keycloak-user] Login timeout

[Bill Burke]

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