Workaround of SameSite default change for Shibboleth SP _shibstate_ ?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Workaround of SameSite default change for Shibboleth SP _shibstate_ ?

Takeshi NISHIMURA
Hi all,

I found it is difficult to conditionally add SameSite=None to _shibstate_ cookie.

We use Shibboleth SP and Apache httpd on CentOS 7.
By the following configuration I succeeded in adding SameSite flag to e.g. JSESSIONID, but it resulted in no effect for Shibboleth SP's cookies.

> Header edit Set-Cookie ^(.*)$ $1;SameSite=None

I know we can add SameSite by cookieProps but I want to do conditionally, due to old Safari.

Does anyone suffer from the same problem?

BTW,
the following sentences mean "Cross-Domain" rather than cross-site. I've misunderstood that.

> 3. Let “target” be the *registrable domain* of “request”'s current url.
> 4. If “site” is an exact *match* for “target”, return “same-site”.
> 5. Return “cross-site”.

Thanks in advance,
Takeshi
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Workaround of SameSite default change for Shibboleth SP _shibstate_ ?

Cantor, Scott E.
On 1/31/20, 5:17 AM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:

> I found it is difficult to conditionally add SameSite=None to _shibstate_ cookie.

I imagine it's impossible, the module has to set its headers with an outbound filter trick to keep them from being messed with, and they probably go out after modules like mod_headers run.

The relay state one really isn't a high priority issue, it's the session cookie that creates the problems in real cross-site applications. Most clustering scenarios can probably rely on memory-based relay state, and if not, I'd just switch to by-value until a better fix emerges.

I will almost certainly be stuck implementing this idiotic dual cookie fix before Chrome drops the two minute grace window, which their last update is confirming they're going to do at some point.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Workaround of SameSite default change for Shibboleth SP _shibstate_ ?

Phil Pishioneri
In reply to this post by Takeshi NISHIMURA
On 2020/1/31 5:16 AM, Takeshi NISHIMURA wrote:
> I found it is difficult to conditionally add SameSite=None to _shibstate_ cookie.
>
> We use Shibboleth SP and Apache httpd on CentOS 7.
> By the following configuration I succeeded in adding SameSite flag to e.g. JSESSIONID, but it resulted in no effect for Shibboleth SP's cookies.
>
>> Header edit Set-Cookie ^(.*)$ $1;SameSite=None


In my testing (on an IdP with apache httpd in front of tomcat), I had
two forms of that directive active:

Header always    edit Set-Cookie (.*) "$1; SameSite=none"
Header onsuccess edit Set-Cookie (.*) "$1; SameSite=none"

The SameSite web page I had found recommended the "always" version, but
I found I had to use the "onsuccess" one, and decided to keep both
active (on a test system). (And yes, I realize that putting that on an
IdP most likely won't help anything.)

-Phil

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]