How does Netskope
work with Okta?

Release Date: 12/08/2021

When it comes to securing web traffic within a business there are three baseline requirements:

  1. The applicable traffic has to be inspected.
  2. The users generating the traffic have to be identified.
  3. Policies need to be created for said traffic and these have to be applied to applicable users.

Traffic Steering

With Netskope, as we are using a cloud tenant for inspection, the user does not have to generate their traffic while on premise or have it ‘hair pinned’ back into the corporate network so that it can be passed through a physical appliance sitting at the network edge within a company data centre. This means they can essentially be located anywhere in the world and have security applied to their web traffic.

The above is particularly key in line with Covid lockdowns, working from home and the general nature of modern working practices where employees can be based anywhere in the World.

The easiest way to do this is by installing a Netskope client onto the user’s device which in turn will steer their web traffic to the Netskope cloud tenant. Steering policies can also be created to granularly control which web traffic is to be sent to the tenant if required.

Now that we have the means of traffic being inspected, we move on to identifying the users who are generating the traffic. One method of doing so is via Okta integration for user enrolment and by using Okta, a whole host of features are made available.

User Management

With Netskope & Okta’s partnership, integration between the two products is relatively straight forward:

https://www.netskope.com/partners/okta  

https://www.okta.com/partners/netskope/

An application exists within Okta called ‘Netskope User Enrolment’ that allows for SCIM integration with Netskope:

This app is easy to configure and comes with clear instructions as to how to do so both within Netskope and Okta.

Once done, provisioning groups can be created and populated with users within Okta which in turn are automatically pushed out to the Netskope tenant.

Within Somerford Associates, we are currently using this integration of Netskope and Okta to secure our production instance and here you can see that my Okta account is being pushed to Netskope as I belong to the Technical group:

At the point of installation of the client on my machine, I am asked to authenticate using Okta to identify who I am and also tell Netskope that traffic generated on my device belongs to me:

Based on Okta’s configuration, this also allows for MFA to be applied to add an additional layer of security to the identification and authentication process. In the below Google Authenticator is being used for quick and easy MFA enforcement but Okta provides a variety of such factors such as it’s own Okta Verify app, SMS, etc:

Granular controls can also be applied to policies such as in the example below whereby we are asking that the user re-authenticate via Okta when they attempt to perform a risky activity within a specific cloud app:

Okta would also allow for the enforcement of reauthentication of the user based on it’s own configured criteria such as time since last authentication, device the user is using, specific activity within Netskope (i.e. a policy violation), etc.

Tenant Administration

While the above relates to End User Management of Netskope, Tenant Administration is also key and Okta can be used to add additional layers of control to who is logging into the Netskope Tenant.

Remember, your Netskope tenant is a public facing cloud login page, hence fully securing it is a must to any organisation as should be the norm for any public facing cloud login page.

Within Okta another app exists called ‘Netskope Admin Console’:

This app is again extremely easy to configure both within Okta and Netskope and allows for Administrators and Roles to be managed and provisioned from Okta to Netskope.

This in turn also allows for further controls to be applied such as MFA whenever an admin logs onto the tenant to perform administrative tasks.

Policies

As per requirement three for securing web traffic, we need policies to control where a user can go and also the activities they can perform when they get there.

Since we are pushing users and groups from Okta to Netskope, we can now create our policies using these same groups to make securing web traffic all that much easier.

In the below example, you can see that I could create a policy based on a single user, or by a team group, both of which have been pushed to the Netskope tenant from Okta:

Visibility

Within the Netskope tenant, I can now also get rich visibility of activity which can be drilled down to single users:

Or based upon the overall Team Group that has been pushed from Okta:

Reverse Proxy

All of the above relates to the use of a client on a device, but what happens when a user logs into an Cloud application from a personal device or any device with no client installed.

This is where Netskope’s Reverse Proxy comes into play and they have an app in Okta for this too:

This app allows for integrating Okta with Cloud SaaS apps, while also integrating with Netskope at the same time.

Using Salesforce as an example, we essentially integrate Salesforce with Okta so that users are authenticated to the application using their Okta credentials.

But behind the scenes, we also tell Okta to point the user’s traffic once authenticated to Netskope.

To the user, Salesforce looks exactly like Salesforce as this integration allows for a seamless experience but when you look at the URL the user is visiting, the presence of rproxy.goskope.com indicates their traffic to and from the app is actually going through the Netskope tenant:

Now, any policies that exist such as uploading or downloading Malware or DLP to or from Salesforce can be applied with security controls being enacted, even when the user is accessing the app from a device that does not have a Netskope client installed on it.

This is an extremely important consideration given the nature of Cloud applications that have public facing login screens that can essentially be logged into from anywhere and from any device. With the above, not only do you get centralised user management, but also MFA and full security of Netskope regardless of where the user is logging on from and from what.

Workflows

The final consideration for Okta and Netskope integration is the ability to create Workflows to automate user and group management, provisioning and deprovisioning using both API calls and Okta’s Workflow feature.

Using simple API calls, users and groups can be deprovisioned from within Okta using some basic configuration elements from Netskope such as the tenant SCIM url and actionable values / commands.

Within Okta itself and via it’s Workflow Console, the lifecycle of user and group management can also be fully automated and bolstered with events such as emailing managers when users have been added/removed from groups.

Conclusion

When it comes to securing web traffic & cloud application usage in this SASE / Cloud driven world, consideration has to be given to integrating security tools such as Netskope and Okta to fully experience the benefits that both tools grant.

As an example, Netskope can be integrated easily with Active Directory, however in doing so Domain Controllers are required be they on prem or hosted within a Cloud Provider.

Further software is required to create a secure connection between these Domain Controllers and a Netskope tenant in order that user/group provisioning & authentication can take place.

With Okta, none of this additional hardware or software is required.

Using Okta also opens up the additional features such as providing users with MFA controls, granular security controls in relation to user behaviour, Reverse Proxy features and automated workflows.

Both tools are native to the cloud and extremely easy to use via their intuitive UIs and detailed instructions & help guides.

Okta & Netskope Webinar

For additional information on integration between Okta and Netskope.

Scroll to Top