About SAML

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.

The Zscaler service supports SAML 2.0 and above. To learn how to configure SAML for your organization, click How do I configure 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 base 64-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.

The service supports both service provider-initiated and IdP-initiated SAML deployments, as well as SAML auto-provisioning.

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.

IdP-Initiated SAML

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.

SAML Auto-Provisioning

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.

See How do I configure SAML?