WSA HTTP Header Rewrite
Available Languages
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
AsyncOS 14.0 is the latest release of Cisco's Web Security Appliance, an enterprise network proxy solution. One of the many features in this release, HTTP Header Rewrite, can be very useful for adding, removing, or even modifying HTTP request headers' content. Use multiple HTTP headers to enhance security, including some well-known or standard HTTP headers, like X-Forwarded-For (XFF) or Via (which displays the Proxy-in-the-network). HTTP headers allow network admins to send the authentication headers containing a username and groups for proxy authentication with Active Directory or Cisco Identity Service Engine (ISE) providing the user identity information.
The addition of this feature provides the WSA with the ability to modify HTTP headers as needed. A common use case allows an administrator to authenticate users against the WSA (client-side proxy) and have the WSA forward the authentication headers to the upstream proxy for user Identification using the header information to apply appropriate policies.
Microsoft Office 365 Tenant Restriction
An administrator may want to allow users access to the organization’s Microsoft 365 applications while preventing access to other organizations’ instances of these applications. With tenant restrictions, organizations can choose the tenants' list that their users can access and specify it in HTTP headers. Azure AD then only grants access to these permitted tenants.
For each incoming request to login.microsoftonline.com, login.microsoft.com, and login.windows.net, the proxy inserts two HTTP headers: Restrict-Access-To-Tenants and Restrict-Access-Context.
For this use case, an administrator may set policies in their network to restrict which YouTube videos are available to employees or students. For this purpose, the YouTube-Restrict header provides options to set strict or moderate rules for users.
Restrict Users Access to Google Suite Applications
Like the previous use case, the WSA uses Header Rewrite to block user accounts from accessing specific google services. An administrator can prevent users from signing in to Google services using Google Accounts other than those explicitly specified.
Use the X-GoogApps-Allowed-Domains header to list registered Google Workspace domains.
Managing SaaS Applications using Azure Tenant Restriction
WSA Header Rewrite works with Azure and other SaaS applications (like Office 365 or Dropbox) to provide user tenant restrictions. Many organizations moving to cloud-based applications, combined with traditional on-premise managed applications that worked with Windows Active Directory (AD), now want their Identity and Access Management (IAM) to work seamlessly for their network users. The increasing demand for secure Single Sign-On (SSO) while retaining traditional Active Directory as the primary IdP (Identity Provider) has many enterprises moving towards Microsoft Azure Active Directory as a cloud-based IAM.
Domain user permissions present a more significant challenge for organizations. As a result, Microsoft Azure restricts enterprise user access and user authentication using Azure Active Directory. The Restrict-Access-To-Tenants HTTP request header takes advantage of these restrictions by using a comma-separated list of tenants to allow user access. The Restrict-Access-Context header uses a single directory ID value to declare the tenant setting the tenant restrictions.
Below provides step-by-step guidance on configuring the WSA to restrict enterprise domain users access to SaaS applications:
Step 1. In the WSA UI, navigate to Web Security Manager > HTTP Rewrite Profiles and click on Add HTTP Rewrite Profile HTTP Rewrite Profiles
Enter a Profile Name and add these two headers:
Restrict-Access-To-Tenants and Restrict-Access-Context
Step 2. Refer to the Azure Tenant’s dashboard for the Restrict-Access-To-Tenants and Restrict-Access-Context.
Step 3. Next, ensure the Security Services > HTTPS Proxy is enabled. Verify Web Security Manager > Decryption Policies is set to either decrypt or monitor for Microsoft domains or your enterprise application gateways. You can use Microsoft Office 365 feeds and custom categories on the WSA for Microsoft-specific URIs.
Step 4. Navigate to Web Security Manager > Access Policies. Add a new access policy for the SaaS, Computers and Security, Office 365 based feeds, or Custom categories and assign the HTTP Rewrite profile to this access policy.
To test if the defined Azure AD users can only access your enterprise applications, try logging in with any other account that is not part of Azure AD. Access should be blocked as shown below:
Use an enterprise domain user account to verify you can successfully login to your organization’s Office 365 tenant.
In conclusion, the WSA Header Rewrite feature enables the ability to insert or remove standard or custom headers into HTTP packets as they pass through the WSA to help with various use cases beneficial to most organizations.