SP/IdP not honoring SSO session

[Morgan, Andrew J]

Hi David,

Maybe the problem has something to do with sameSite cookies?  I remember there being some strange time limits on how Chrome (and Firefox?) handle cookies without sameSite set.  I'm sure others on this list know more about it than me...  The inconsistency of the SSO session cookie behavior is what reminds me of sameSite.

Andy

________________________________
From: users <users-bounces at shibboleth.net> on behalf of IAM David Bantz via users <users at shibboleth.net>
Sent: Thursday, February 6, 2025 4:39 PM
To: Shib Users <users at shibboleth.net>
Cc: IAM David Bantz <dabantz at alaska.edu>
Subject: SP/IdP not honoring SSO session


[This email originated from outside of OSU. Use caution with links and attachments.]

A newish service inconsistently honors users' existing SSO sessions.

The initial signin link (in our student portal) issues a request to a service with Issuer and ACS suggesting OAuth:

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://....oauth....com:443/saml/SSO" Destination="https://sso.civitaslearning.com/realms/alaska-prod/protocol/saml" ForceAuthn="false"... IsPassive="false" IssueInstant="..." ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> https://....oauth....com:443/saml</saml2:Issuer> </saml2p:AuthnRequest> That service in turn sends a request to our institutional SSO (Shibb IdP): <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceURL="https://sso..../endpoint" Destination="https://idp.alaska.edu/idp/profile/SAML2/POST/SSO" ForceAuthn="false" IssueInstant="..." ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <saml:Issuer>https://sso....</saml:Issuer> </samlp:AuthnRequest> Users must have created an SSO session to get to that first link inside the student portal, and I've verified SSO to other services without forcing re-authentication. ForceAuthn is "false" for the two requests as indicated in snippets above. Nevertheless, users generally have to re-authenticate to our institutional IdP for that second service. I wondered if some process involved in that cascade of saml requests destroyed or invalidated the SSO session cookie. But I verified that after the demand for re-authentication, but prior to re-authenticating, other SSO-enabled service all work as expected, relying on the initial SSO session used to sign in to the student portal. The behavior described is not consistent - generally re-authentication is required in Chrome, but not in Firefox, and sometimes yes, sometimes no in a Chrome incognito window. Users and administrators rightly object to this behavior and want SSO to be honored. I won't poison the well with my unfounded speculations, instead asking for your constructive ideas on how to track this down. (Yes, we've asked the vendor, who has so far responded with crickets.) David St Pierre Bantz
UA IAM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250207/cbc308eb/attachment.htm>