Zscaler App with Org2Org SAML Auth and SSO


I have the following question around SAML Auth with Org2Org integration.

We have configured Zscaler for SAML authentication via Okta and this one works well with SSO. Users onprem are redirected to IWA and are authenticated transparently - no user/Zapp interaction is needed. We then moved further and tried extending this to Org2Org (Okta “federation”).

Org2Org integration works well - users are populated from Okta Tenant B into Okta Tenant A and from there are provisioned into Zscaler. There’s only one thing which we don’t like and I am not sure if Zscaler can help resolving it at all…

Users in Tenant B use different domain (it is provisioned on Zscaler cloud). To be able to redirect them to Tenant B IdP in Okta we had to configure Authentication Rule to look for @domain-B and in this case redirect to Okta in Tenant B.

IWA works well for Tenant A, as well as standard SAML flow
IWA works well for Tenant B, as well as standard SAML flow

The difference is that when Zscaler redirects user who belongs to Okta Tenant B to Okta Tenant A (initial auth), a blank username prompt appears because IWA rule is not being hit in Okta Tenant A… so user MUST enter full UPN/email to make sure Okta Tenant A can detect he belongs to Okta Tenant B, once user puts the username and presses Enter, user is redirected to Okta Tenant B and IWA sequence in Okta Tenant B kicks in and user is seamlessly authenticated (no password prompt)

Is there anything at Zscaler end (App specifically) that can help to populate full username into IdP username prompt and submit it transparently on user’s behalf?

I’ve noticed there’s feature

Automatically populate Username field for IDP Authentication

But it is only available starting from App v2.1 (we are on 1.5) and I am not even sure if this is what I am looking for


You’re right: since ZIA only has 1 SAML definition it will always redirect to that IDP and it doesn’t really interact with the user, so there’s not much it can do to change this behavior.

If I understand you correctly, Tenant A can’t authenticate the user (it failed IWA) and now needs to figure out how to continue. You’ve set up a rule to redirect @domainB user to tenant B, but Okta hasn’t received an actual username yet, so it prompts the user to provide one.
I think you may be able to solve this in the authentication flow by first running local IWA and then use tenant B as automatic fallback option (so not limited to @domainB users). Note that ‘anonymous’ users will then use tenant B’s fallback option which could impact fallback for domainA users.

The ‘automatic username population’ feature won’t help you solve this; it’s actually reverse. Z-App already does this if a user typed in their username in Z-App; this feature provides the option to disable this (in case your security policy demands users to type their user-ID. Yes, there are use cases for this).
Looking at your description I presume you’ve installed Z-App with your org-ID (and potentially cloudname) to provide an SSO user experience. But this means the user never entered their user-ID in Z-App (good) so Z-App can’t provide it to the IdP (bad).

Note that this wouldn’t be a problem if ZIA were to support multiple IdPs (like ZPA does); in that case you could tie domainA and domainB to their respective IdPs and redirect accordingly. ZIA would still first have to figure out which domain that user belongs to (effectively the same problem as Okta is facing) but here the ‘userDomain’ installation feature in Z-App would tell ZIA which IdP to choose.
As said, MIdP is already supported in ZPA, but not in ZIA. There’s an ER for ZIA to do the same but it will have quite some impact on ZIA and MA so I have no idea when/if this will be implemented.

1 Like

Thank you @jhage!

What you suggested will work if you have single Orge2Org integration :slight_smile: It won’t work if there are multiple business integrated firms with multipe Org2Org integrations :slight_smile:

Yes, we’ve installed ZApp with the userDomain option (which belongs to a single cloud, so no need to provide cloudname). Yes, you are correct and it makes sense… user has never entered his username in SSO flow, hence Okta is unaware who he is. I thought Zapp is somehow capable to detect username/domain on the fly as PC is domain-joined and user has logged in to W10 using his credentials. So, my assumption was that it shouldn’t be ‘impossible’ for Zapp to take this username and possibly populate it into IdP presented page (and potentially submit it). But yeah… I get it is difficult as there are multiple IdPs and it might not be that simple to maintain this functionality.

What you explained does make sense to me, except the one related to ‘Automatically populate Username field for IDP Authentication’… it is disabled by default, so I read it - if I enable it then some sort of automatic population will be happening… but tell me it’s reverse? Not sure I understand it :slight_smile:

Looks like the only PROPER way to resolve this is MIdP, so I am looking forward for this feature :slight_smile:

Thank you again. Much appreciated!

Glad I could help. Yes, if there are even more parties involved it gets ugly real soon; no way to properly chain this unless you control all IdPs.

To further explain the ‘username population feature’ you can take a look at https://help.zscaler.com/z-app/configuring-automatic-username-population-idp-authentication:

“The Zscaler App (Z App) automatically populates the username field for your organization’s IdP login form. If your IdP requires the user to type in their username” [aka: not use the default behavior] “you can disable the app from automatically filling in the username”.

I’ve added your organization to the ER requestor list (assuming you are indeed the person I found on Linked-In)