Using SameSite=none for unauthenticated users, but SameSite=lax for authenticated users?

[tepid relic]

Basically, I'm trying to get SAML Responses that use HTTP Post bindings to work. Obviously POST is not allowed cross-site when SameSite=lax and thus this breaks the SAML flow when using it and checking the relay state, and in response to attributes.

Is there a built in way in Laravel to make unauthenticated user's cookies be SameSite=none, but then once the user authenticates switch to lax?

If not, I'm assuming the best place to handle this would be in a new middleware that invalidates the old cookie if the user is authenticated and it is same site none with a new cookie that is same site lax?

I'm curious if anyone knows of something someone has already written out there that handles this situation also.

[ashen nacelle]

Is it possible to use a route outside of the web middleware group for the POST bounceback (such that a new session is not created)?

[tepid relic]

Would this be different than adding an exception to the VerifyCSRF middleware?

Is the web middleware what determines to set the SameSite to lax?

[ashen nacelle]

I thought the problem was that cookies are not sent. If the problem is only CSRF, then definitely add a CSRF exception

[tepid relic]

The issue is the cookie not being sent is the browser's decision

Because samesite=lax disallows a cookie to be sent from the browser to the issuing website if another website issues a POST request to the issuing website

Maybe I misunderstood your comment?

[ashen nacelle]

Yeah, so CSRF configurations won't help. But if you use another middleware group, which doesn't have "StartSession", it won't create a new session

But you won't be able to tie the response to the session either, unless you redirect again and pass information

[tepid relic]

Oh interesting so create a special bounceback that specifically does not create a new session when missing a session (which it would be becaue of SameSite=lax), but then redirect from that immediately to the callback with all the parameters from the original SAML Response so that the cookie does get passed properly?

[ashen nacelle]

Yeah if you can pass on the same data, that could work.

But you need to think through security, so you don't do something stupid like POST to /login?user_id=123 and just blindly trust that

[tepid relic]

oh yeah that would be silly, but that's the SAML Trust's / SAML SP package's job which I trust to have done it right

I'll have to double check if it cares about the issuing location as part of the SAML Response verification

but the above could work - I may also just fix the package to actually just do a redirect when directed to do so - because it's really annoying the writer just defaulted to POST

[ashen nacelle]

I did something similar once, where the redirect from SAML to Laravel (on the same domain) used a signed URL with an HMAC

[tepid relic]

Okay dope, I'll give this a shot I really appreciate it @ashen nacelle 🙂

[ashen nacelle]

In my case the problem was that the SAML package had conflicting dependencies with Laravel, so I had to use separate index.php files

[tepid relic]

Ah, I'm using one that's from the SocialiteProviders package which seems pretty active and well maintained

https://github.com/SocialiteProviders/Saml2