Q. How do you enforce Netskope Client adherence without impacting SAML flows after authentication?
A. Netskope Client Enforcement.
Netskope Client Enforcement is used to “enforce” the compliance of having a Netskope client enabled and connected to a tenant for accessing SaaS applications using Identity Providers (IdP) such as Okta. This includes IdP or Service Provider initiated connections, i.e. logging into Okta to access a SaaS application or logging into the SaaS application directly.
Netskope Client Enforcement should be differentiated from other methods of steering real-time traffic to the Netskope tenant for the processing of policies; policies such as Next-Generation Software Web Gateway (NG-SWG), Data Loss Prevention (DLP), Netskope Private Access (NPA), User Enhanced Behavior Analytics (UEBA), Cloud FireWall (CFW), and so on, all of which are designed to protect an organization. Netskope Client Enforcement also enables end users to protect corporate resources through compliance.
NOTE: Other methods of steering real-time traffic to Netskope may be used as well to accomplish the same goal as using the Netskope Client for Netskope Client Enforcement, i.e. Cloud Explicit Proxy. However, we are going to cover using the Netskope Client for simplicity.
Netskope Client Enforcement does not:
Netskope integrates with Okta to allow an organization to enforce steering cloud application traffic to Netskope for analysis. This is accomplished through access control to the Okta tile representing a SaaS application in the IdP. Access control is met by using an Access Control List (ACL) composed of IP addresses owned by Netskope, either the shared address space utilized across tenants or IP addresses unique to each customer, a new feature offering called Egress IP.
The ACL is then applied to the SaaS application Okta tile to allow access if originating from a Netskope IP address. If the remote user is not originating from a Netskope IP address, the user will not be able to access the Okta tile, which will have a lock on it.
NOTE: The Egress IP feature is a service offering which requires an organization to reach out to their Customer Experience team or reseller to purchase.
We are restricting access to SaaS applications regardless of IdP or SaaS initiated authentication. We want to limit access to those resources originating from specific IP addresses which are part of the Egress IP feature mentioned earlier. Egress IP addresses are typically two IP addresses per dataplane; and, of this writing there are 63 dataplanes which is 126 unique IP addresses.
There are two prerequisites for Netskope Client Enforcement.
Open the Netskope Client Enforcement page and locate the Setup section, upload the Okta.cert file downloaded above. Click on Preview File to confirm this is the correct certificate.
It is necessary to edit templates for Download Request for operating systems currently in use within the organization.
Once the Netskope Client Enablement application is configured in Okta, assign users the application and those applications to have access restricted to only those IP addresses assigned to them by Netskope proxies.
When a user logs into Okta they will be presented with the applications assigned to them. If they have the client on, applications assigned to them and which are being protected will not have a lock on them; the Netskope Client Enablement application will have a lock on it.
NOTE: Using Cloud Explicit Proxy will also yield the same result as the Netskope Client enabled and connected to a tenant, sourced from Netskope proxies. However, that is outside the scope of this document.
When a user does not have the enabled and connected to a tenant, the Netskope Client Enablement application will be unlocked; all applications which have access restricted to them will be locked.
When a user accesses a locked application, a page will be displayed indicating that application access has been locked.
When a user accesses the Netskope Client Enablement application when it is unlocked, they will be redirected to the Netskope tenant to verify they have been provisioned.
If users encounter locked Okta applications after enabling the Sign On policy or policies, the issue might be related to the Sing On policy itself. Check to see if access to the application is denied if the end user is not coming from a Netskope IP address, Not in Zone and Deny access is the action set.
If users encounter a locked Netskope Client Enforcement application after enabling the Sign On policy, check to see if access to the application is denied if the end user is coming from a Netskope IP address, In Zone and Deny access is the action set.
If they are still seeing a lock on the applications, check to see if the IP addresses from which the user is sourced is in the Networks Zone IP address list.
Go to https://notskope.com examine the section “Your source IP address is <insert IP address>”.
If the client is enabled and connected to a tenant, there will be an indicator on the map for the dataplane from which the user is sourced. The X-Forward-For (XFF) IP address will be that of the ISP to which the user is located.
The Netskope Client Enforcement application in Okta may be used as a self-service option in Okta to deploy the Netskope Client. It is possible to create an additional Netskope Client Enforcement application and name it “Netskope Client Self-Service Install” or instruct users to use the same application for both purposes.
In order to view this content, you will need to sign in to your account. Simply click the "Sign In" button belowSign In