Provisioning and Authenticating Users
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 powerful reporting capabilities of the Zscaler service, provisioning and authenticating users are required. Provisioning involves uploading usernames, 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, and 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. But to leverage the granular department, group and user policies and the ability to track usage trends by department and user, an organization must provision its users and enable authentication.
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 username, 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 are some guidelines for provisioning users:
Users can be included as criteria in policies, and in reports and analytics as well. The username must be in the form of an email address. It does not have to be a valid email address, but it must be unique and its domain must belong to the organization.
Groups can be included as criteria in policies. You can control access to apps based on user groups. For example, you can define groups and policies based on the apps that users are allowed to access. You can create a facebook-users group and a twitter-users group, define a policy that allows access to facebook and apply it to the facebook-users group, and define another policy that allows access to twitter and apply it to the twitter-users group. Users can belong to one or both groups, depending on their business needs. A user can belong to up to 128 groups.
Like users, departments can be included as criteria in policies, and in reports and analytics as well. Therefore, consider your reporting needs when defining departments in the Zscaler service. Ensure that the departments are structured correctly so that you get the correct department-based reports. Unlike groups, a user can belong to only one department. The service tracks usage at the user level. If a user belonged to multiple departments, then they would be reported multiple times. Additionally, with the role-based administration feature, administrators can have control over a set of users in a department. When you set up administrators, you can define their scope by department. If users belong to more than one department, this can cause conflicts.
Authenticating Users from Known Locations
The following diagram illustrates how ZENs handle HTTP traffic from known locations.
Authenticating Users from Unknown Locations
The following diagram illustrates how ZENs handle HTTP traffic from locations that are not configured on the Zscaler service.
**For example, when applications don't support cookies or when an unknown user agent is used.