A SAML logon flow with HTTP POST binding (SAML Bindings 2.0, section 3.5) runs (roughly) as follows:
- A browser makes an unauthenticated request to a service provider. The service provider responds with an HTML page that redirects the browser to the identity provider (with a SAML request in the payload). The response contains a "relay state cookie" that contains information about the request.
- The browser makes a POST request to the identity provider with the SAML request in the payload and (assuming the user is already logged on there, so the request contains a session cookie) receives an HTML response that redirects it again to the service provider (with a SAML response in the payload).
- The browser makes a POST request to the service provider with the SAML response in the payload and the relay state cookie in the header.
- The service provider validates the SAML response and knows which user made the request. It uses the information from the relay state cookie to execute this request on behalf of the user.
The requests in steps #2 and #3 are cross-site, because they go to the identity provider or service provider, respectively, but were triggered by an HTML page from the service provider or identity provider, respectively. In order for the session cookie or relay state cookie to be included in this request, these cookies must have SameSite=None
(but see here).
The pen test complaint therefore seems unjustified.
An alternative would be HTTP redirect binding (SAML Bindings 2.0, section 3.4) that uses GET instead of POST requests. In that case, SameSite=Lax
would be sufficient for both involved cookies.