Zscaler is the market leading cloud proxy service. I have implemented Zscaler for a number of customers in the Transport and Government sector over the last 3 years and its adoption is rapidly increasing as customers look to migrate services to the cloud, increased workforce mobility, a move to OPEX based services and away from traditional on-premise CAPEX heavy forward proxy solutions like Bluecoat. Note. Bluecoat do offer a cloud service but it is doesn’t have the maturity and cloud scale that Zscaler has built up as a pure cloud player over the last 10 years.
There are many ways to authenticate users of the Zscaler service, locally defined database, LDAP and SAML to name the main ones. However the problem comes in populating the user database. If you had a small organisation (sub 50 users) then a locally defined user database might work for you, however most organisation are way above this figure and want to leverage their existing Identity management system such as Active Directory or Azure AD. Now this is fine as we can integrate Zscaler into both of these IDPs using SAML. However populating the user database depends on your requirements. We can auto-populate (preferred) the Zscaler user database using the data from the SAML tokens, which is great as each time the user authenticates to Zscaler their information is updated! This works great when using Active Directory (ADFS) or Azure AD (see my other articles on how to integrate these). However when using AzureAD the user’s group membership cannot be added to the SAML token. You could define local groups in Zscaler if that meets your requirements however if like most organisations you are migrating from an on-premise forward proxy solution to Zscaler then chances are you will want to ease the pain by using the existing AD groups which are used to define your proxy policy. With ADFS we can insert the AD Groups that the user belongs to in the SAML token, it just puts a dependency on having an ADFS infrastructure in place or building one.
The other options are LDAP or Zscaler Authentication Bridge (ZAB). Where you could still carry out user authentication via SAML but populate the Zscaler user database using LDAP or the ZAB. I don’t like either of these solutions. Exposing your domain controllers to the Internet, albeit source IP restricted doesn’t feel right to me, it also puts a dependency on LDAPS being in place which a lot of organisations still don’t use. I guess you could use LDAP but i’m not even going to suggest exposing your IDP data unencrypted over the Internet. and the ZAB, what’s the point of a pure cloud proxy solution if you have to put a VM in your on-premise data centre to sync your user data. (Also Bluecoat’s and Cisco Umbrella’s solution) Also the ZAB is currently only supported on VMware so you couldn’t even host this is Azure or AWS!
I like the elegant solution of authentication and auto-populating the user database using SAML. I’ve spoken to Microsoft about being able to include Groups in the SAML token when using Azure AD as the IDP and it doesn’t seem to be supported for Zscaler. Note. You can modify app manifest files to populate User Groups in the SAML token for other apps so you maybe able to do this for Zscaler. Off topic, I don’t understand why Azure has App registrations and Enterprise Apps, this should be merged! Zscaler is deployed as an Enterprise App as such there is no Manifest file to modify, So you would have to manually register the app if this is even possible. I would hope, as this is not the only use case, that Groups will be possible using Azure AD at some point, Microsoft have got pretty good at listening to the community now that they have other options.
Links
Network Jigsaw 