User unable to access ZTNA segment application after authenticating to Cloud SWG.

Products

• Symantec ZTNA

Issue/Introduction

Cloud SWG and ZTNA both authenticate users using an Okta SAML Identity Provider.

Segment applications enabled on ZTNA side for users running WSS Agent to be able to connect to.

Test user has been assigned a new OKTA ID, and this same user was added to the ZTNA POC Group.

After the user successfully logs into Cloud SWG and can browse protected web sites via Cloud SWG without issues, the same user is unable to connect any internal ZTNA segment based applications.

User reports getting standard browser "unable to load the page" error accessing some internal web based applications pointed at by segment application.

Cloud SWG access logs report the user and Web site details; ZTNA forensic logs do not show any information about the user.

Environment

ZTNA.

Cloud SWG.

SAML Authentication.

WSS Agent.

Cause

Non unique user in Okta Identity Provider user store.

Resolution

Configure the Cloud SWG (not ZTNA!) Okta Identity Provider to send a unique subject ID within the assertion.

Additional Information

Using the SAML tracer output, the assertion Subject name identifier includes the [email protected]. WHen the ZTNA service is passed this identifier/email address, it queries the Okta Identity provider for a unique ID within the user store ... which was failing with our setup as the email address is NOT unique.

The problematic user(s) had initially worked as contractors with an identifier of [email protected] before being hired permanently, when the same user was given a new unique identifier ([email protected]). The original user entry was not deleted but simply marked inactive, but more importantly both had the Email attribute of [email protected]. When the ZTNA service queried the Okta user store for a user with the [email protected] email address, it got two matches and failed as it expected a single match.

By configuring the Cloud SWG Okta Identity Provider to send an assertion name identifier with the value [email protected] instead (available on Okta application side), no conflict existed and all worked.

Another solution would have been to go back to the Okta team and either

• remove the old entry OR
• keep the old inactive entry but change the email attribute from [email protected] to [email protected] (or anything that is unique).