institutions using Shibboleth to authenticate Peoplesoft

[Cantor, Scott]

On 7/28/20, 4:40 PM, "users on behalf of Liam Hoekenga" <users-bounces at shibboleth.net on behalf of liamr at umich.edu> wrote:

>     Oracle didn't like / understand relayState.

You need a POST to work, that's all that's relevant to the use case.

The SP session cookie is not SameSite safe. Ergo, POST is not going to resume the old session unless that's fixed, so even if there were no timeout, you'd be interrupted.

Fixing that with 3.1 might reduce the frequency of interruption of sessions but it won't eliminate them unless timeouts are infinite, so post preservation is still a requirement in the bigger picture. Reducing it is good, but you can't eliminate it.

Preserving POST is not just memory, it has its own cookie, prefixed by _shibpost_, with a unique name that's based on the RelayState that's about to go out to the IdP. The value is the key to the storage record with the data. It is always a cookie, even if RelayState itself is not backed by one. This prevents misuse of RelayState to just steal form data from another client mid-flight.

At that point, Chrome kicks in and destroys all sanity. <2 minutes from SP to IdP and back, and you should be fine. The POST data cookie will be submitted along with the SAML POST, and the data recovered, and the final step is a form generated to replay the POST back to the URL instead of a redirect to it. > 2 minutes, and the POST cookie will not be available, and you lose the data.

> If we're capturing the POST data and relayState in shared memory, and the application / SP has multiple nodes, the LB
> has to be configured to enforce session stickiness.  The operations group for that team swears that it is.. but would this
> behavior suggest otherwise?

If you can't make the round trip work in a browser other than Chrome, then yes. If it's only Chrome and only when it's >2 minutes logging back in after the POST to Peoplesoft is interrupted, then I would probably blame SameSite.

> Should we be looking at the sameSiteSession setting in SP 3.1?

If you want Chrome to work regardless of login delays, then you have no choice. The POST feature requires the cookie make the round trip work. It's one of the use cases that is vulnerable to SameSite errors.

-- Scott