Configuring direct set cookies

At times you may encounter applications that set cookies on direct request that prevents or breaks a login attempt to an application with users being sent through the Forcepoint ONE SSE reverse proxy.

When this occurs admins can configure a redirect to force the cookies to be sent through the request when going through the reverse proxy. This setting is configured on a per app basis.

First let's go over what to look for when we perform a SAML trace. We must identify 4 main things.

  • URL Look Up: This is the main URL that is being called, do not include the "https://" portion of the URL
  • Method: The method of the request, this can be any method (GET, POST, PUT, etc)
  • Cookies: The cookie that is being set directly and not being passed.
  • Redirect URL: The URL (rewritten for the reverse proxy) that we need to redirect to, do not include the "https://". This will be the first request that initiates the SAML GET request.

If you have an application where you can login successfully via direct app access but fail to login or receive an error when trying to go through the Forcepoint ONE SSE reverse proxy then you are likely encountering direct set cookies that are not being carried over during the proxy redirect. To find the URLs, request, and cookie open up a SAML Trace program (for example SAML-tracer addon in Firefox) and attempt to login to the application going direct.

  • In the SAML trace we need to look for the last SAML request being made before Forcepoint ONE SSE logs you into the application. It's important to remember the login flow to ensure you are looking at the correct request. As a user attempts to login to the application they are redirected to Forcepoint ONE SSE. If you also have a separate external IdP setup, Forcepoint ONE SSE will then send you to that IdP for authentication. The IdP will then send a request back to Forcepoint ONE SSE and then Forcepoint ONE SSE will finally log you in.
  • In this trace example, you will see 2 different pairs of SAML requests. The first pair is the first redirect to Forcepoint ONE SSE and then to the external IdP. The 2nd pair, the pair we want to look at, is the redirect back to Forcepoint ONE SSE and then to the application for final log on.


  • Inspect that final SAML request in the second pair and look at the cookies. We are looking for a cookie that is static and does not change per request. You will likely need to run another SAML trace and attempt a login again in order to compare the two to verify that the cookie remains persistent across sessions. We just need the name of the cookie (and not the value it is equal to). From this we can grab the first 3 items we need.

    • URL Lookup: "us1a.app.anaplan.com/samlsp/login/callback
    • Method: POST
    • Cookie: "auth0"
  • After that we need to look back at the entire trace and grab the URL that initiated the entire SAML flow in the first place. We then need to manually rewrite it for the reverse proxy (change periods to dashes and append the domain with the Bitglass domain .btglss.com. The URL for this is us1a.app.anaplan.com/samlsp/LZDCASB. Converted we get:
    • URL Redirect: us1a-app-anaplan-btglss.com/samlsp/LZDCASB

Once we have all the pieces of information we need above, you can now setup the JSON code to ensure the direct set cookie is included in the reverse proxy requests.

  1. When logged into the Forcepoint ONE SSE, navigate to the Protect > Policies page and select the app in question to get to it's settings page:

  2. On the apps settings page, select Configure Direct Set Cookies option.

  3. Delete out the comment line of the top but you can leave the example JSON there since it is formatted for what we need. What these 4 lines of code are doing is saying, when we see the URL and method check to see if the cookie is present. If the cookie is not present then redirect to the URL at the bottom and grab the cookies.

    • URL_to_look_for: This is the primary URL to identify the request that is missing the cookie when going through the reverse proxy. Again we don't need the "https://". For our example above
    • method: The method of the request being made.
    • cookies: the cookie name that is missing in the request that we need to ensure is included.
    • URL_to_redirect_to: The initial URL that contained the direct set cookie(s) that we need to redirect back to. This should be the URL rewritten for the reverse proxy without "https://"
  4. Now we just have to fill in the proper information, click Validate JSON and click Ok then click Save when we are back on the app settings page.