Having recently completed the integration of Netskope Private Access (their ZTNA component) with our existing Okta instance for SAML-based authentication, I found the process to be methodical but with several non-obvious configuration points that are critical for a seamless user experience. The documentation covers the basics, but a practitioner's view of the actual steps, including the nuanced mapping of user groups to access policies, seemed to be lacking. This post details our implementation workflow, pitfalls encountered, and verification steps.
**Primary Objective:** To leverage our central Okta Identity Provider for user authentication into Netskope Private Access, ensuring that existing user groups (e.g., `engineering`, `finance-contractors`, `all-employees`) could be directly utilized within Netskope's Real-Time Policy to govern application access.
### Step-by-Step Configuration & Key Screenshots
**1. Okta Application Configuration**
* Within Okta, a new "Netskope Private Access" app was created using the "Web" > "SAML 2.0" template.
* The critical settings here are the **Single Sign-on URL** and **Audience URI (SP Entity ID)**, both provided during the Netskope tenant configuration. These must match exactly.
* We configured the attribute statements as follows. The `groups` claim is paramount for policy mapping.
```xml
Attribute Statement:
Name | Name Format | Value
-----------------|---------------------|------------------------
email | Unspecified | user.email
groups | Unspecified | user.groupMembership
firstName | Unspecified | user.firstName
lastName | Unspecified | user.lastName
```
**2. Netskope Tenant SAML Identity Provider Setup**
* Navigate to **Settings > Authentication > Identity Providers**.
* Create a new SAML IdP, uploading the IdP metadata XML file downloaded from Okta.
* The **User ID Attribute** was set to `email`. The **Group Attribute** was set to `groups`.
* *Pitfall:* The group attribute value arrives from Okta as a semi-colon delimited string. Netskope correctly parses this, but your Okta group names must not contain special characters that could break the regex parsing.
**3. Mapping Okta Groups to Netskope User Roles**
* In **Settings > Authentication > User Roles**, we created roles corresponding to Okta groups (e.g., `okta-engineering`, `okta-finance-contractors`).
* The role assignment rule was defined using the `saml_group` attribute. For example:
`saml_group contains "Engineering"`
* *Verification Step:* Use the "Test Rule" feature extensively with real user profiles from your Okta to ensure the `saml_group` value is being read correctly.
**4. Configuring Real-Time Policy for Access Control**
* With roles established, access policies in **Settings > Private Access > Real-Time Policy** can be defined using `user_role` as a condition.
* Example policy to grant access to an internal engineering tool:
* **Application:** `eng-tool-01.corp.internal`
* **User / Group:** `user_role` `in` `okta-engineering`
* **Action:** Allow
* *Critical Note:* The order of policy rules is evaluated top-down. We placed more specific application rules above broader, catch-all rules.
### Post-Integration Validation Checklist
- [ ] Initiated SAML login from Netskope client to ensure IdP redirection works.
- [ ] Verified successful authentication and that the Netskope client session shows the correct `username` pulled from SAML.
- [ ] Checked Netskope audit logs (`Settings > Audit`) to confirm the user's mapped role is populated post-login.
- [ ] Tested each access policy with users from different Okta groups to ensure correct allow/deny behavior.
- [ ] Validated that deprovisioning in Okta (user removed from group) reflects in Netskope access within the expected token refresh window.
The integration is now stable, providing us with a centralized access governance model. The main latency we observed is tied to Okta's SAML assertion caching; changes in group membership can take up to the SAML token lifetime to be reflected in Netskope. For immediate revocation, we are exploring Netskope's SCIM integration as a next step.
— Amanda
Data > opinions