IIS Module Intermittently Failing to Query Daemon over a TCPListener for Session Information

[Nate Klingenstein]

For the record, we finally managed to roll this change out in a production environment this morning, and it looks like sameSiteSession=None and "secure" was the fix.  We couldn't use the https shorthand because we have to handle vanity domains, but so far, so good.  No looping.

Thanks again,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

-----Original message-----
From: Cantor, Scott
Sent: Friday, July 9 2021, 1:16 pm
To: Shib Users
Subject: Re: IIS Module Intermittently Failing to Query Daemon over a TCPListener for Session Information

On 7/8/21, 6:23 PM, "users on behalf of Nate Klingenstein" <users-bounces at shibboleth.net <mailto:users-bounces at shibboleth.net> on behalf of ndk at signet.id <mailto:ndk at signet.id>> wrote:

>    The application in question uses iframes extensively and the browser traces from clients show the OpenSAML
> cookie being set with SameSite None, but without a secure flag.

That's simply controlled in the usual way, the SP sets all its cookies with secure if you tell it you, which obviously is the normal way it should work.

>    So, is it plausible that this is a SameSite issue and that the proper fix is that cookieProps needs to be set to
> "https" and a new sameSiteSession attribute needs to be added with a value of "None" to the session element?

The correlation cookies are always SameSite=None. The sameSiteSession option is for controlling the session cookie when applications have to honor cross-site behavior.

Basically unless you deliberately turn off the secure flag, there's no reason it should be a problem apart from the broken client thing.

-- Scott

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>