The push for work-from-anywhere and the increasing need for a zero trust architecture (ZTA) significantly accelerated the adoption of Zscaler Private Access (ZPA) as a leading solution for many organizations. With a massive number of ZPA users, it's now common for two partnered companies to need to access resources through each other's ZPA instances. The previous approach to this was to log out of one tenant and log in to another, but this approach has two main issues related to:
- User experience
- Security posture
In some cases, ZPA users need to access resources or applications hosted by other companies; which might happen to have a ZPA solution as well. For example, consultants and partner companies might have ZIA and ZPA access from their sourcing company, and during contracting, they may need to access the internal resources of the partner company. With this comes a need to securely access partner tenants along with an improved design to allow ZPA users to navigate smoothly between resources hosted by these companies.
In addition to the end user experience, the new design is needed to enhance security posture by allowing users to keep internet security services (e.g. Zscaler Internet Access, or ZIA) active while accessing the partner resources. This is critical to maintaining ZTA as users will be protected against external threats while accessing the partner resources. The Zscaler Client Connector and ZPA team worked closely to improve the current design, user experience, and security posture. With multi-ZPA tenant user access, users who need to access resources owned by other companies (Zscaler customers) can do so by adding the new tenant without logging out from their Client Connector or disabling ZIA.
To maintain security and ZTA concepts, Partner Login Access of the end user is controlled by admins. End users must prove their identity (authentication) and admins will grant access to needed applications only (authorization), and provide visibility to who can access what. To access other companies’ resources, the administrators for the secondary tenants should explicitly grant users access by allowing partner access in the Client Connector portal, and providing the credentials needed to authenticate against their identity provider. Once access is granted, the partner tenant administrators should configure the required applications/resources to be accessible to those partners/contractors. This task is mandatory to grant access because the default is to block all—no users will gain access until administrators explicitly configure it. The users can stay logged in through their primary company ZIA tenant, keeping that security, while accessing a partner ZPA tenant. Flowchart 1 illustrates the process that end users will go through to connect to a secondary tenant.
Flowchart 1
Figure 1 below shows the UI of the Client Connector that supports this feature (the feature should be enabled by admins). As shown in the image, the end user can easily connect to a partner tenant by clicking on + Add Partner Tenant.
Figure 1
To enable those using this functionality, we added two knobs in the Client Connector Portal; the first one to allow the partner to connect to this tenant (users still need to authenticate), and the second one to allow users of the primary tenant to connect to other ZPA tenants (Figure 2).
Figure 2
If a user who has access to this feature decides (the second knob is enabled on the primary tenant side) to add a tenant by clicking on + Add Partner Tenant, the user will be prompted to type the ID in UPN format if the second knob is enabled on the secondary tenant side (Figure 3-a). The UPN format input will be used to detect the secondary company IDP by looking up the entered domain. Then, the end user will be redirected to their IDP page to authenticate (Figure 3-b).
Figure 3-a
Figure 3-b
Once the user passes the authentication process, the new tenant will be added to the UI as shown in Figure 4. Once the tenant is added, the user can switch between the primary tenant and the secondary tenant smoothly without the need of logging out.
Figure 4
Finally, the secondary tenant administrator should configure the required access policies with the client type “Client Connector Partner” to grant access to the partner’s users as shown in Figure 5. Adding the Client Connector Partner as a new client type improves the security posture by blocking users' access if they try to connect as a primary not secondary. For example: if user A from the primary company decided to log out from the Client Connector and log back in with the secondary tenant’s credentials, user A will have no access to the secondary tenant applications because the connection is not coming from the secondary channel. This helps the secondary tenants to make sure that users from outside their organization access their applications while ZIA service is running on their machines.
