. See here in
more readable form:
Feedback welcomed.
In shortcut, I've tried to add 2 approaches. The "minimalistic" should
fix the "You are already logged-in" and shouldn't be too hard to
implement. It doesn't involve any JS tricks, but involves not removing
root auth session at the authentication finish and support for
redirecting to the applications instead of showing "You are already
logged-in" message.
The advanced approach tries to address usability even more. It contains
the JS tricks and shared authentication session per all browser tabs. It
overs cases like "Client overriden flow" as well. This will be more work
and depends on priorities and time if we have time to incorporate this too.
Marek
On 16/06/2019 10:18, Stian Thorgersen wrote:
On Fri, 14 Jun 2019 at 17:53, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Thinking more about this and have some more points inline.
Dne 13. 06. 19 v 18:17 Stian Thorgersen napsal(a):
> Discussed this with Marek a bit and may have a potential
solution here.
>
> My suggestion is the following:
>
> 1. Add a timestamp to a cookie - this timestamp is updated
whenever the
> user makes any action in the authentication session. Basically
submitting
> any form.
> 2. Add a piece of JS that reads the value of this cookie. If the
value
> changes it will refresh the page. This will hand over the logic
of what to
> do now to the Keycloak server. If username/password was
submitted on one
> tab, the second tab should automatically update and show the
next step (or
> if complete redirect to the client with successful login)
So just to clarify, this would also mean that we will track the
"authentication state" informations (executions, authNotes,
requiredActions etc) per RootAuthenticationSession, not per
AuthenticationSession. Correct? Because authentication state will be
shared per whole browser, not per individual tabs as it is now. So
just
the "client state" will need to be shared per individual tabs.
ATM I am not seeing any reason why it won't work. But it will require
some more refactoring...
Yes, we'd need to share the authentication state across multiple tabs
> 3. Change the client_id param to a more generic state param.
This should be
> a base64 encoded value with the info that we need in case root
> authentication session is lost
(base64(c=<client-id>&r=(redirect-uri). With
> having a single param base64 encoded we can more easily add
additional info
> if we need without having to add more query parameters.
I wonder that if instead of just clientId + redirectUri, we can
add the
parameter, which will contain all the client informations encoded
in the
JWS token? Something similar/same like current KC_RESTART cookie,
which
is JWS encapsulating all the client state sent from the OIDC or SAML
client. The advantages of this approach:
- Less informations on the server side. Especially with the
"authentication state" shared globally per rootAuthSession and
with the
"client state" in the parameter, we "usually" (see below for why
word
"usually") won't need to track any state on the server side. So we
will
be "usually" able to remove RootAuthSession directly after
authentication finished as it's now.
- We will be able to remove KC_RESTART cookie. This cookie is not
very
great anyway as it encapsulates info just from the single browser tab
- Less probability of redirecting to the client with the error as all
the client info are available in the token param.
Disadvantage:
- There are some cases that client info in the JWT will be bigger
than
2000 characters limit [1]. In that case, we will need to fallback and
will still need to track the client info somewhere else that in the
request parameter. Either on server side (hence still a need to
have the
list of AuthenticationSessions attached to RootAuthSession) or per
the
cookie, which is not limited in the size. The support for the
fallback
will require some more refactoring...
It's slightly more complicated to keep all state in a JWT, but
probably ideal at least when the session isn't too big. Perhaps we
could do the fallover thing we discussed in the past. As long as JWT
is smaller than 2KB we just add it to a cookie, but if it gets to big
we add a reference in the cookie and store the values server side in a
session.
Would be worth trying to think this one through properly and see if we
can solve this once and for all.
[1]
https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-...
Marek
> 4. Root authentication session should not be deleted straight
away if there
> are more child authentication sessions, but rather it should be
garbage
> collected after X mins of inactivity.
> 5. If root authentication session is garbage collected we should
redirect
> to the client with login error, rather than display error page,
with some
> error message stating failed due to inactivity. The client can
then handle
> it accordingly.
>
> On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik <vramik(a)redhat.com
<mailto:vramik@redhat.com>> wrote:
>
>> Hi,
>>
>> I'm working on
https://issues.jboss.org/browse/KEYCLOAK-5179 See if
>> message "You are already logged-in" can be avoided during
authentication.
>>
>> In current state we discard the RootAuthenticationSession when user
>> successfully finishes the authentication. In that moment we
loose all
>> the information stored in AuthenticationSession(s) for other
tab(s) and
>> in some cases we do not know where to redirect the user. To
solve this
>> issue there seems to be 2 possibilities.
>>
>> 1. Do not remove RootAuthenticationSession once the user
finishes the
>> authentication. Instead we can remove just AuthenticationSession
>> associated with the specific tab from the
RootAuthenticationSession and
>> the RootAuthenticationSession would be deleted together with last
>> AuthenticationSession from it.
>>
>> 2. Add and pass redirect_uri parameter to login flow. With the
parameter
>> we'd always have an information where it should be redirected
in case
>> the authentication was successfully finished in other tab.
>>
>> With solution #1 it'd increase the memory as it keeps
>> RootAuthenticationSession alive till all tabs are alive.
>>
>> Solution #2 keeps current behavior regarding the authentication
sessions
>> but it slightly increases the length of uris.
>>
>> wdyt?
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev