SP/IdP not honoring SSO session

[IAM David Bantz]

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/20250206/8b3fed3d/attachment.htm>