'keepIdPSessionAlive'

[Cantor, Scott]

> The idea is for the browser/client to ask the IdP to keep the SSO session alive
> for another interval, so that the user does not have to authenticate/login
> again until the interval has elapsed.

The IdPSession has a timeout, but that session is necessary but not sufficient for SSO, and if it's expiring too soon, the solution is really just to give it a long timeout.

But even if you keep it alive, that won't give you SSO. That can only happen if the AuthenticationResult inside the session stays alive, so what you're really talking about is that timeout.

I don't really understand why the solution isn't just to give the authentication flows a longer timeout. The browser polling doesn't prove the user's still there, or that it's the same user sitting there, it just means the browser's sitting there polling.

What I mean is, you have the cookie. If you poll or don't poll, the thing that gives you any confidence it's legitimate later is the cookie. No difference that I can see.

> What do you think ? Any pitfalls ? Is it possible ?

Yes, it's possible, but it's not (just) the IdPSession you have to touch, it's one or more AuthenticationResults, and it's not clear how you would decide which ones to affect.

Actually, I'm pretty sure you could do all this today with a dummy SP stood up with some metadata to drive the IdP to do a regular transaction. If the state of the session was amenable to SSO, that alone would update the timestamps and if you set it up to do, e.g. an artifact response or even use CAS, it would be redirect based, so a background request could navigate it. The dummy SP wouldn't even need to be real, just enough to respond at a URL to make it seem like the response from the IdP was delivered and leave it at that.

> I’m thinking an IdP endpoint could expose the storage service, so yes, I’m
> assuming server-side storage.

Third party cookies would work fine also. Local storage of course wouldn't.

So, nutshell, I'd just throw a dummy SP in and have the browser hit an IdP-initiated request and call it a day. No development needed.

-- Scott