ssoSessionMaxLifespan SAML and OIDC use collide

Hi,

we’ve been using Keycloak for a while now, and internal use is starting to gain some steam. We use it for a few SAML SaaS applications and our own version of Gatekeeper (over OIDC). Everything has been great for the most part (besides having to dig up some old SO posts about scripting and hacking basic authorization into SAML).

But we’re really not happy about ssoSessionMaxLifespan.

Let’s say we have a compliance requirement to lock out a user after they are removed from Keycloak (or the attached LDAP in this case) after at most 24 hours. Because various SAML RPs (e.g. Github) will keep their own sessions alive for way longer than a day and stick to the SessionNotOnOrAfter of the AuthnStatement, we’re now forced to set ssoSessionMaxLifespan to 1d. But this is really bad for our OIDC clients. There, it doesn’t really matter how long a session is, as long as the ID/access token is only valid for a short amount of time and refreshing will ensure the user still exists. But now they’ll have to reauthenticate every 24 hours, possibly getting pulled out of their app while working on something.

Is there any way to split up those two very different timeouts? I’m not exactly a Java programmer, but I took a glance at the code and it seems to be hardcoded in there.

1 Like

We are planning on introducing “client sessions” which will allow having different timeout for clients compared to SSO session. See https://issues.redhat.com/browse/KEYCLOAK-12103 for more details.