When the customer does the first request with a new browser (clear cache, cookies...), they are able to route through the gateway to authenticate with the "require Windows integrated authentication credentials" assertion.
As expected, the first request will be answered with a 401 and the browser should send the Negotiate Authentication Header:
When they press F5 to do a refresh, the gateway answers with the 401 and then stops with a 400 Bad Request.
When the second response comes back with a Set-Cookie, the browser or HTTP client automatically replaces the old cookie with the new one.
If the Broadcom CA API Gateway is changing that cookie — even slightly — it can break the session.
Typical cases are:
It overwrites the session ID with a new one that the backend doesn’t recognize.
It sends a cookie with an empty value or expired date, effectively logging you out.
It changes the cookie’s domain or path so the browser won’t send it on the next request.
It adds a SameSite or Secure flag that causes the browser to ignore it in certain requests.
Once that happens, the third request (or anything after the second) is sent with the wrong cookie, so the backend rejects it — making it look like “something broke” after the second request.
When you strip out the Set-Cookie from the second response, the browser keeps using the original working cookie from the first request, so everything works fine.
How to fix without stripping Set-Cookie in the CA API Gateway:
1. Check policy for “Manage HTTP Cookies” or “Insert Response Headers”
Remove or adjust it so that the gateway passes Set-Cookie unmodified.
2. Enable “Preserve Multiple Set-Cookie Headers” in HTTP routing assertion (important for RFC compliance).
Turn off SSO cookie issuance if it’s not required for the API.
3. Match the backend’s cookie settings (domain, path, Secure, SameSite) so the gateway doesn’t break scope.