Zscaler recommends deploying Identity Federation using SAML (Security Assertion Markup Language) for provisioning and authenticating users. This article provides an overview of using SAML for provisioning and authenticating users for the Zscaler service.
To learn how to configure SAML for your organization, click How do I configure SAML?
The Zscaler service supports SAML 2.0 and above.
The service supports both service provider-initiated and IdP-initiated SAML deployments, as well as SAML auto-provisioning.
Background on SAML
SAML (Security Assertion Markup Language) is an XML-based structure that is used to organize users’ security and identity information, and to distribute this information across the organization’s boundaries to other entities. It enables the following entities to exchange identity, authentication, attribute, and authorization information:
- A principal, which is a user who is trying to access a service or application online
- A SAML authority, also referred to as the identity provider (IdP), that authenticates the user
- A relying party, which is the service provider that relies on the IdP to authenticate the user before it allows access to the service or application
SAML provides for a federated identity wherein partner services use the same name identifier to refer to a user. It also enables Single Sign-On so users can authenticate only once to an IdP and then access various services.
SAML achieves this through a collection of assertions, protocols, bindings, and profiles
Assertions: A SAML authority creates statements regarding any of the following:
- The authentication of a subject
- A subject’s attribute information
- Data of a subject in regards to a specific resource
Protocols: Request/response protocols that allow the service providers to:
- Request one or more assertions from a SAML authority
- Request an identity provider’s authentication for a principal and return the corresponding assertion
- Request the registration of a name identifier
- Request the termination of an identifier’s use
- Get back a protocol message requested by means of an artifact
- Request a single logout for a collection of related sessions
- Request mapping of a name identifier
- Bindings: A binding defines how the SAML protocol messages are sent over transport and messaging protocols. The Zscaler service supports the HTTP Post Binding which Defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.
- Profiles: A profile defines the assertions, protocols and bindings used for specific use cases.
For more information about SAML, refer to https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
Service Provider-Initiated SAML
The most common deployment is the service provider-initiated SAML deployment where the user tries to access a web site and is redirected to the Zscaler service, which then sends a SAML request to the IdP. The IdP validates the user’s credentials, gets user attributes like group membership, and returns the SAML Response assertion to the Zscaler service through the user browser. The following figure illustrates the process in detail.
In IdP-initiated SAML, a user can log in directly from an SSO provider's portal by clicking the Zscaler application icon. When the user clicks the Zscaler application icon, the IdP generates a SAML response which is posted to Zscaler at:
For example, if your organization is on the zscaler.net cloud, the SAML response is posted to Zscaler at: https://login.zscaler.net:443/sso_upd/123456.
The service obtains the login name and optionally the group, department and user names from the SAML response. (Note that the SAML response must be 4 MB at the most.) To ensure security and prevent man-in-the-middle attacks, the Zscaler service requires that the SAML response be digitally signed by the IdP. If required by the IdP, the service can also digitally sign its request.
You can enable SAML Auto-Provisioning to allow the service to automatically retrieve information related to users/groups/departments from the SAML response and automatically add the information to the database. It can also automatically update a user's group membership based on the information retrieved from the SAML response. (Note that the SAML response must be 4 MB at the most.)
- If the user does not exist in the database, it is added into the database along with the group and the department values. This new user is activated and all relevant policies are enforced.
- If the user exists in the database, the user display name, group and department values in the SAML Response are updated into the database.
- If the user display name, group and department values do not exist in the SAML Response, then these values are removed from the database too.