Users accessing internal applications via Cloud SWG integrated with ZTNA using WSS Agent.
SAML authentication enabled to 3rd party IDP server without any SCIM interface.
Users are provisioned to the ZTNA Identity provider user store via the SAML attributes sent with assertion.
Most users can access the ZTNA segment application without issues, but a handful cannot; the same users can access non ZTNA applications fine.
Users seeing issues reported authentication versus access related errors.
Cloud SWG.
ZTNA.
Generic SAML user provisioning.
Problem users had moved from one group to another group within the enterprise, where they had a different internal ID but the same email address e.g. a user with ID [email protected] and [email protected] were both created on the IDP server user store with the email attribute of [email protected].
When ZTNA processes the assertion and tries to identify the user, the incoming email address from the assertion could not be tied to a single unique user.
Change the IDP server integrated with Cloud SWG (not ZTNA) to send a unique identifier and not the email address shared between two different IDs.
In the above case, we changed the UPN in the Cloud SWG IDP server to the user id (not email address) so ZTNA uses this unique ID not the email address for identifying users and querying the users groups.
ZTNA has a feature called internally as "upn_id" which allows us to define the id that ZTNA will use to query the IDP server ( (note attribute 'e' in step 4 section 4).
When the Cloud SWG admin configures SAML with Cloud SWG, they can pass a metadata field that tells ZTNA what to use when searching for the user later on in the ZTNA side. If nothing is passed in the "upn_id" field the default behaviour is to use the NameId field in Cloud SWG SAML which is in the [email protected] format and not the [email protected] format.
To fix this we changed their IDP integration in Cloud SWG to pass the upn_id metadata that is in the [email protected] format.