[keycloak-dev] Cookies & RememberMe clarification
Marek Posolda
mposolda at redhat.com
Tue Sep 16 09:52:04 EDT 2014
On 16.9.2014 12:28, Stian Thorgersen wrote:
> To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.
yeah. But besides validity of the KEYCLOAK_IDENTITY cookie, I would say
that identityToken tight to the cookie should be set to
ssoSessionMaxLifespan as well?
Fact is that KEYCLOAK_IDENTITY cookie is tight to the UserSession. But
KEYCLOAK_IDENTITY cookie is refreshed just during SSO login, when
UserSession.setLastSessionRefresh is called either during SSO login or
refreshing token. This could lead to the situation when UserSession is
still valid, but token from KEYCLOAK_IDENTITY cookie is expired, hence
user is logged out even he has valid UserSession (my example 1 from
previous mail) .
>
> With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).
Maybe yes. My understanding of rememberMe is that you may need to
automatically login from your browser even after very long time (in
days), hence I meant to not tight it to UserSession. But maybe it's just
me:-)
I meant to address stuff like logout of all sessions from acct
management with the persistent rememberMe records. So when someone wants
to logout all sessions, it would clear rememberMe records too (Similarly
when realm.notBefore is set by admin or other similar actions). It would
be quite amount of work and model, so if we can live with tight
automatic relogin just to UserSession, it's fine with me.
>
> As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.
ah, ok. So KEYCLOAK_REMEMBER_ME cookie will be used just as a 'hint' to
prefil login form then? I can add support for this though. As actually
KEYCLOAK_REMEMBER_ME cookie is not used for anything.
Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 16 September, 2014 12:09:07 PM
>> Subject: [keycloak-dev] Cookies & RememberMe clarification
>>
>> Have few questions related to cookies & rememberMe.
>>
>> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
>> default (so expires when browser is closed). Thing is that lifespan of
>> the identityToken generated in AuthenticationManager.createIdentityToken
>> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
>> cookie is refreshed just during cookie SSO login. So for example when I
>> have scenario like:
>> * Login to admin console
>> * Do some admin work for 15 minutes
>> * Then click to "Manage my account" button (or to some other Keycloak
>> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
>> valid anymore, so I am immediately logged out. Note that UserSession is
>> still valid as I had couple of refreshToken requests during my 15
>> minutes 'admin' work.
>>
>> So my question is if we can use ssoSessionMaxLifespan for the identity
>> token instead of ssoSessionIdleTimeout? Note that even in cookie
>> authentication, we are also checking if UserSession is valid. So if
>> UserSession is expired, the login won't be successful anyway.
>>
>> 2) Second thing is RememberMe feature. Actually we have
>> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
>> rememberMe. But this cookie is actually not used anywhere for relogin!
>> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
>> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
>> cookie will survive and you will be able to relogin.
>>
>> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
>> for example if I have scenario like:
>> * Login to admin console
>> * Close my browser and wait 15 minutes
>> * Then open my browser and try to relogin --- ATM both UserSession and
>> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
>> work and Keycloak login screen is displayed to me.
>>
>> Also scenario like:
>> * Login to admin console
>> * Close my browser and restart Keycloak
>> * Then open my browser and try to relogin --- rememberMe also won't work
>> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
>> UserSession provider).
>>
>> IMO RememberMe shouldn't be tight to particular UserSession. I would
>> expect that when I start browser next day, I will be automatically
>> logged in even if my UserSession from previous day is already expired.
>>
>> It seems that to properly support RememberMe, we should use
>> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
>> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
>> privateKey and valid just for one use (Each RememberMe login will
>> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
>> This would mean that we will need to persist stuff related to rememberMe
>> with some additional related informations (realm, user, timestamp,
>> ipAddress). So for example if admin will set Not-Before for realm, it
>> will also invalidate all stored rememberMe tokens.
>>
>> It seems that this will require some model changes and amount of work,
>> but ATM RememberMe feature seems to be quite unusable to me.
>>
>> wdyt?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
More information about the keycloak-dev
mailing list