HTTP URL Rewriting
Operating in the in-band mode of data protection against SaaS applications, DSG is placed between the end-user’s client devices and the SaaS servers on the public Internet. For DSG to intercept the traffic between end-user devices and SaaS servers, the top level public Internet Fully Qualified Domain Names (FQDN) that are made accessible by the SaaS need to be identified. Once identified, these FQDNs shall be mapped to internal URLs pointed at DSG and the corresponding URL mappings shall be configured in DSG.
Like most websites on the public Internet, SaaS applications are accessed by their users through one or more Uniform Resource Locators (URL). These are typically HTTP(S) URLs that are made up of FQDNs, e.g. https://www.ffcrm.com, which are uniquely routable on the public Internet. A SaaS may be accessible on the public Internet through many public facing URLs. An identification of all such public URLs is essential for ensuring that all the traffic between the end users and the SaaS can be routed through DSG. A list of top level Internet facing FQDNs of a SaaS may be gathered from the following sources:
- SaaS Support Documentation: SaaS providers typically provide publicly available documentation where they publish their externally visible FQDNs. This information typically exists for the IT teams of customer enterprises such that they can allow - allowed list - access to these FQDNs through their corporate firewalls.
- Using Browser Tools or Network Sniffers: As an alternative or in addition, the IT team at Biloxi Corp may attempt to find the public FQDNs of ffcrm.com themselves. This can be achieved by making use of network sniffers - possibly an embedded function within Biloxi Corp’s corporate firewall or a forward proxy.
An alternative is to use ‘developer tools’ in the user’s web browser. Browser developer tools show a complete trace of HTTP messaging between the browser and the SaaS. If all relevant sections of ffcrm.com SaaS have been accessed, this trace will reveal the relevant public FQDNs made visible by ffcrm.com.
As a result of performing the above steps, let’s consider that the IT team at Biloxi Corp has identified the following top level public FQDNs exposed by ffcrm.com.
www.ffcrm.comlogin.ffcrm.comcrm.ffcrm.comanalytics.ffcrm.com
For DSG to interwork traffic between its two sides (end users and SaaS), DSG relies on FQDN translation. The following figure shows FQDN translation performed by DSG.
The above domain names will be mapped to internal domain names pointed at DSG. For instance, DSG will be configured with following URL mappings.
| Incoming Request URL | Outgoing Request URL |
|---|---|
https://www.ffrcm.biloxi.com | https://www.ffcrm.com |
https://login.ffcrm.biloxi.com | https://login.ffcrm.com |
https://crm.ffcrm.biloxi.com | https://crm.ffcrm.com |
https://analytics.ffcrm.biloxi.com | https://analytics.ffcrm.com |
This domain name mapping can be generalized by configuring a Domain Name Service (DNS) with a global mapping of *.ffrcm.biloxi.com to DSG which will apply to any of the sub domain www, login, crm, analytics or any other that might be added by ffcrm.com in the future.
Ultimately, end users will be consuming the service through the internal host names. Techniques like Single Sign On (SSO) using Security Assertion Markup Language (SAML) can be used to force users to use internal host names even if direct access to the external ones is attempted.