Configuring HTTP Request Headers

When using the SWG, customers can also configure policies to send over HTTP request headers during authentication to apply more granular controls within the application itself.

Note: The header insertion is supported for managed applications and for the SWG (SmartEdge Agent and Cloud SWG).

For example, Microsoft provides some headers that when sent in the SAML request can control which M365 tenants are accessible. This means admins can configure contextual policies to restrict users from accessing specific tenants. You can find information on login tenant controls for Microsoft and Google at their respective support guide pages.

Steps

  1. Navigate to Protect > Policies on a per policy basis for the application. This means you can apply these login controls contextually based on the user/group, device, location, and so on.
  2. Start by creating a new policy line or editing one of your current policy lines under the Action column.


  3. Scroll to the bottom of the Action dialog window and check the HTTP Request Headers box to display the table. Here you can add as many headers as you want to be sent during the SAML request when a user authenticates to an application.


  4. Add an item to the table and then select an Action from the drop-down and then configure the appropriate header Key and Value that you wish to be sent.
    Note: The HTTP request header's Value field is limited to a maximum length of 255 characters. Saving the policy with more than 255 characters will truncate the characters down to the first 255 characters.


    Each application will have a different header that is used to control access to specific tenants/domains.

    • Add/Replace: If a matching key exists, all values will be overwritten. If a match is not found, the key will be added. This action allows fixed values along with the following macros as sometimes the value to be set is dependent on the source device IP address or username and so on.
      • $(source_ip) - Use this macro to insert the IP address of the source device. This is the Gateway IP address displayed in the logs for agent and cloud-swg.
      • $(username) - Use this macro to insert the username of the user originating the connection. This is the username displayed in the logs. If the user is __anonymous, then $(username) will be __anonymous@<domain.com>.
      • $(username_domain) - Use this macro to insert the domain name of the user originating the connection. For example, if the user is test@acme-gadget.com, then acme-gadget.com is the domain. If user is __anonymous, then $(username_domain) will be derived from __anonymous@<domain.com> and set to <domain.com>.
    • Remove: If a matching key exists, all key value pairs for that key will be removed.
    • Append: If a matching key exists, existing values are preserved and new values are appended.
  5. For our example of using Google, the header is X-GoogApps-Allowed-Domains with the value being the domains (separated by comma).


    For the above example, users matching this policy line will only be able to access the following Google domains: acme-gadget.com, acme-gizmo.com, and acme-gadget.net. They will be blocked from accessing any other domains preventing users from accessing their personal Google accounts while using a managed device with the SmartEdge Agent.