Skip to main content

User Guide - Using WPC for role-based access control to SaaS applications

Overview

In this document, we examine a WPC set up to meet the needs of a fictitious company. This company based in the USA has a Sales team located in California and a technical support team in the midwest. The sales team uses a SaaS application called Salesforce and the support team uses a SaaS application called Zendesk. The company also uses OneLogin as its IDaaS provider for Single Sign-On (SSO) implementation.

Owen is in charge of IT and Networking for this company. Owen is already using CloudConnexa for the company as a solution to provide employees with Remote Access to private Network resources. He now wants to add additional protection for the usage of SaaS applications by enforcing role-based access control at a Network-level.

Objectives

  1. Enforce role-based access control to SaaS applications at the Network-layer by only allowing employees in specific departments access to applicable SaaS applications. For example, only employees in the Sales department can access Salesforce.

  2. Only transport traffic to the SaaS apps through the WPC while traffic to other internet destinations is transported outside the WPC. For example, internet traffic to Google does not use WPC but traffic to Salesforce and Zendesk is transported inside the WPC tunnel.

  3. Route SaaS traffic via CloudConnexa Regions that are geographically close to the employees using the application to improve Network performance.

  4. In order to prevent employees from accessing the SaaS apps without using WPC, whitelist the public IP address of WPC exit points in SaaS applications such that only login attempts from that pubic IP address will be accepted.

Solution

The high-level steps for Owen to achieve his objectives are as follows:

  1. Owen needs to know the public IP address ranges of the SaaS applications. SaaS applications generally publish the IP address ranges they use to provide services so that customers can configure their firewalls. For example, Salesforce’s list of IP address ranges can be found here and Zendesk publishes it here.

  2. The public IP addresses of the SaaS applications need to be configured as belonging to private Networks so that traffic to the SaaS applications enters the WPC.

  3. The Network configured to represent the SaaS applications can have one or more Connectors. The Regions that are chosen for these Connectors can be in geographic proximity of the locations from which the employees will log in to the applications. See, User Guide – Using multiple connectors to increase reliability of remote access to learn more about how smart routing is used to improve Network performance.

  4. The computing instances running the Connector for these Networks need to be set up as an Internet Gateway using the public IP address for NAT. These public IP addresses can then be used to whitelist login access in the SaaS apps.

  5. Access Groups need to be used to allow access of specific User Groups to applicable Networks representing SaaS applications.

  6. To enforce role-based access control using SSO, the department of the employees need to be passed as a SAML attribute and mapped to User Group.

Setup

Owen followed the steps shown below to add group-level SaaS access control for the Sales and Support departments to Salesforce and Zendesk respectively.

  1. Configured a Network named ‘SalesforceAccess’ to represent Salesforce and entered the Salesforce public IP address ranges (found here) as the Subnets for the Network. See, How to add a Network

    62ead8444245f.png

  2. Owen configured the Region of the Connector as San Jose, CA because the Sales team was based in California. Using a Virtual Private Server (VPS) hosting provider that had a hosting region near San Jose, he installed the Connector on a Linux VPS and configured the server to act as the Internet Gateway. The server was assigned a public IP address of 104.248.61.65. See, Connecting Networks to CloudConnexa Using Connectors on how to install Connectors and the corresponding settings to enable routing and NAT. We recommend using a Linux operating system.

  3. Next, He configured a Network named ‘ZendeskAccess’ to represent Zendesk and entered the Zendesk public IP address ranges (found here) as the Subnets for the Network. See, How to add a Network

  4. Owen configured the Region of the Connector as Chicago because the Support team was based in the midwest. Using a Virtual Private Server (VPS) hosting provider that had a hosting region near Chicago, he installed the Connector on a Linux VPS and configured the server to act as the Internet Gateway. The server was assigned a public IP address of 167.71.139.124. See, Connecting Networks to CloudConnexa Using Connectors on how to install Connectors and the corresponding settings to enable routing and NAT. We recommend using a Linux operating system.

  5. To allow only the Sales team to access Salesforce, Owen created a new Access Group (see, Adding an Access Group) providing the User Group named Sales access to the SalesforceAccess Network. Similarly, he created another Access Group to provide the User Group named Support access to the ZendeskAccess Network.

    62ead84633893.png

  6. As SAML with OneLogin is being used for User Authentication (see, Using SAML for User authentication with OneLogin as the Identity Provider) and the employee’s department is being mapped to User Group, the access controls configured earlier will work as soon as an employee is authenticated and mapped into the appropriate User Group.

  7. Now, once an employee from the Sales department connects to the WPC, she will get associated with the Sales User Group. The traffic generated by her login request to Salesforce will flow inside the WPC tunnel and will be routed by CloudConnexa to egress out of the San Jose Connector for SalesforceAccess Network. The traffic will have the source IP address of 104.248.61.65 when it reaches Salesforce servers.

  8. In order to prevent employees from directly logging into Salesforce without the use of WPC, Owen has configured 104.248.61.65 as the only source IP address from which to allow logins in Salesforce. See, https://help.salesforce.com/articleView?id=admin_loginrestrict.htm&type=5. A similar precaution is taken by Owen for Zendesk.

With all the configuration done, role-based access control can now be enforced even on SaaS applications at the Network-level.

In this section: