The Zscaler service can enforce web and firewall policies by location, department, group, and user, and it can track internet usage by location, department, and user. To leverage the ability to enforce granular policies and the reporting capabilities of the Zscaler service, provisioning and authenticating users are required. Provisioning involves uploading users, groups, and departments to the service database. Enabling authentication allows the Zscaler service to identify the traffic that it receives so it can enforce the configured location, department, group and user policies, as well as provide user and department logging and reporting.
When a user from an organization with Zscaler deployed opens a browser and sends an HTTP request to a site, the request is redirected to the nearest Zscaler gateway, the Zscaler Enforcement Node (ZEN). The ZEN first checks if the request is from a location defined in the Zscaler admin portal (that is, a known location), or from a location that was not configured on the admin portal (that is, an unknown location).
When the Zscaler service receives traffic from a known location or at a dedicated proxy port that is associated with a location, the service automatically applies the location's policies and tracks internet activity by location. In order to leverage granular department, group, and user policies as well as enable the ability to track usage trends by department and user, an organization must provision its users and enable authentication.
If authentication is disabled for a known location, users are able to access any website, unless there are location-based category or website block policies configured. Also, if users are coming through a location with an unregistered domain, the service will still know the location because the IP address is registered with Zscaler. So, location-based policies are still applied to these users. However, the service will not know who the users are and to which domain they belong to because authentication is disabled. Yet, in some deployments from known locations, by mapping a user to a private IP address, Zscaler can apply the user's policies instead of the location's policies to traffic that it cannot authenticate. This is known as a Surrogate IP. To learn more about this, including how to enable it, see What is Surrogate IP?
When the Zscaler service receives traffic from a location that it cannot identify, it automatically requires users to authenticate themselves because it cannot associate the traffic with a location. In this case, users must be provisioned on the service so it can successfully authenticate them, apply the appropriate department, group, and user policies, and track internet usage.
Provisioning involves uploading user, group, and department information to the Zscaler service database. The Zscaler service supports various provisioning mechanisms, as described in Choosing Provisioning and Authentication Methods. Following guidelines apply when provisioning users, groups, and departments:
The following diagram illustrates how ZENs handle HTTP traffic from known locations:
*For example, when applications don't support cookies or when an unknown user agent is used.
**To learn how to enable IP surrogacy, see What is Surrogate IP?
***To learn more, see About SAML.
****To learn about authentication and provisioning, see Choosing Provisioning and Authentication Methods.
The following diagram illustrates how ZENs handle HTTP traffic from locations that are not configured on the Zscaler service:
*To learn more about dedicated proxy ports, see Configuring Dedicated Proxy Ports.
**For example, when applications don't support cookies or when an unknown user agent is used.
***For more information on authentication methods, see Choosing Provisioning and Authentication Methods.