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