Netskope utilizes the System for Cross-domain Identity Management (SCIM) standard to automate user lifecycle management and synchronize identity data across the Security Cloud Platform. This framework supports native integration with Identity Providers (IdPs) such as Microsoft Entra ID and Okta, facilitating the secure exchange of user and group resources. By implementing RBAC v3 token-based authentication, administrators can establish a persistent synchronization pipeline that reduces manual provisioning overhead and ensures identity consistency.
The architecture supports a high-availability identity model, including Forward Proxy Authentication (FPA) for granular, SAML-based access control and integrated support for the Netskope Enterprise Browser. Organizations can configure up to 150 concurrent SAML accounts to manage diverse access methods—such as IPsec, GRE, and Cloud Explicit Proxy—while maintaining native single sign-on (SSO) workflows for end-users.
Highlights of Provisioning and Authentication
-
Automated Provisioning: Leverages SCIM RFC 7643 and 7644 standards to automate the creation, update, and deactivation of user accounts and group memberships.
-
Token-Based Authentication: Requires RBAC v3 (via Service Accounts) or REST API v2 tokens to authorize secure communication between the IdP and the Netskope tenant.
-
Multi-IdP Support: Enables simultaneous configuration of multiple IdPs based on network location or access method to support complex global deployments.
-
Access Method Integration: Extends identity enforcement to the Netskope Enterprise Browser, allowing for unique license-based activation and authenticated diagnostic verification.
-
Policy Enforcement: Synchronized users and groups are immediately available as criteria for Real-time Protection and Forward Proxy policies.
Provisioning with SCIM
The System for Cross-domain Identity Management (SCIM) simplifies user provisioning by standardizing identity information exchange across different cloud applications. Netskope supports SCIM integration with Microsoft Entra (formerly Azure AD) and Okta, using REST API v2 token authentication. This setup facilitates seamless user management, automating identity synchronization and reducing manual tasks.
Supported Apps for User Provisioning
-
Community Support Apps
* Instructions in this section is applicable only for non admin users. For instructions to configure SSO for admin users, see Single Sign On for Administrators section.
Netskope Entra ID Integration Workflow
To ensure a successful integration and avoid common configuration errors, complete these three phases in the following order:
-
Auth Setup: Obtain a Netskope RBAC v3 token.
-
Generate an RBAC v3 token within the Netskope UI via a Service Account (Settings > Tools > REST API v3).
REST API v2 or the older OAuth tokens are deprecated for new Entra integrations.
-
-
Link IDP and Netskope: Configure the Netskope app in Entra ID
-
Configure the Netskope Gallery app within the Entra ID portal using your tenant URL and the access token from Phase 1. Refer to the User Provisioning with Entra ID guide for step-by-step app creation.
-
-
Configure Attributes (Required): Map standard and custom attributes.
-
Define and map the specific user attributes (standard and custom) that must be synchronized. Refer to the Using Netskope User Authentication App guide for mapping instructions.
We recommend that you complete this phase (configuring attributes) to avoid synchronization issues where users appear in the UI without necessary metadata.
-
Forward Proxy Authentication
Forward Proxy Authentication (FPA) ensures secure access to cloud applications by requiring SAML-based authentication via an intermediary server that allows organizations to enforce granular authentication policies. Netskope’s FPA allows integration of multiple Identity Providers (IdPs) based on criteria like access methods (IPsec, GRE, Cloud Explicit Proxy, NS Client Enrollment) and network location, enabling flexible and secure user authentication management. Organizations can maintain existing SAML setups while utilizing Netskope’s enhanced authentication features, supporting multiple concurrent IdPs to match specific conditions for robust security and control.
Enterprise Browser Integration with SAML Forward Proxy v2
This section introduces native support for the Netskope Enterprise Browser within the SAML Forward Proxy v2 framework. This integration expands the capabilities of the REST API v2-based authentication process and its user interface to include the Enterprise Browser as a configurable access method.
The integration with the Enterprise Browser includes the following updates:
-
API Enhancement: The SAML authentication REST API v2 has been updated. The Enterprise Browser is now recognized as a valid access method.
-
UI Update: The SAML & OIDC settings page (found at Settings > Security Cloud Platform > Forward Proxy) has been updated. A new checkbox for the Enterprise Browser is now available in the Access Method section, allowing administrators to manage its configuration directly through the user interface.
OIDC is currently available as a beta feature. Contact your Sales Representative or Netskope Support to enable this feature for your tenant.
Configuration and User Activation
This section outlines the steps for administrators to configure the feature and for end-users to activate the browser.
Enable Access Method – Make sure the Enterprise Browser is enabled as an authorized access method for SAML authentication.
-
Navigate to Settings > Security Cloud Platform
-
Select Forward Proxy > SAML & OIDC.
-
Find and edit your active SAML configuration.
-
In the Access Method section, select the Enterprise Browser checkbox and Save the configuration.
User Provisioning and Email Invite – Provision the user in the service and generate an email invite that includes a browser download link and a unique license key.
-
Navigate to Settings > Security Cloud Platform > Enterprise Browser > User Provisioning.
-
Select the License Management tab.
-
Click on Invite Users. Locate the target user or user group and click Save. These users will receive an email invite with the Enterprise Browser download link and the license key required for the next step
Enterprise Browser Profile Activation – The end-user performs a one-time activation to link their browser to the Netskope tenant.
-
The user launches the Netskope Enterprise Browser application.
-
If this is a new installation, the user will be prompted to create a new profile. Otherwise, the user clicks Add new Netskope Enterprise Browser Profile.
-
Enter a name for the profile (e.g., your company name).
-
Enter the license key received via email.
-
-
Click Create Profile.
netskope://policy is a diagnostic URL used to verify that the browser profile is successfully linked and receiving policy from the Netskope tenant. While it can be useful for troubleshooting, it’s not a standard step in the end-user activation flow.Authentication and Validation
To validate the workflow and begin Browse with the Enterprise Browser, the user must authenticate through your organization’s Single Sign-On (SSO) provider.
-
In the activated Enterprise Browser profile, the user browses to any website.
-
The browser automatically redirects to the configured SSO provider (e.g., Okta, Entra ID).
-
The user authenticates using their SSO credentials.
-
After successful authentication, the user is seamlessly redirected to their original destination URL.
Multiple and Concurrent IdP
You can configure and concurrently enable multiple IdP services (upto 150 SAML accounts) to authenticate users based on various criteria. The primary criterion, however, is the access method. The supported access method includes:
- IPsec
- GRE
- Cloud Explicit Proxy
- NS Client Enrollment
When enabled, the multiple IdP offers the following features:
- Admin can enable multiple IdP services for different access methods.
- Migrate an existing IdP from the older configuration setup to the new setup and preserve existing configurations.
- When there is more than one IdP for a particular access method, the first matched access method will be used.
- If an IdP service is configured for ALL access methods with additional options for a particular Network Location then only the requests from those network locations irrespective of the access method will use this IdP service.
- Auth service domains need not be explicitly mentioned in the domain bypass.

