Skip to main content

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

Overview

In this document, we examine a WPC setup 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 applications. He now wants to add additional protection for using 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 uses the local internet route. For example, internet traffic to Google does not use WPC, but traffic to Salesforce and Zendesk is transported inside the OpenVPN tunnel to the WPC.

  3. In order to prevent employees from accessing the SaaS apps without using CloudConnexa, 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 domain names belonging to the SaaS applications. For this example, it is salesforce.com and zendesk.com.

  2. The domain names of the SaaS applications need to be configured as Applications belonging to private Networks so that traffic to the SaaS applications enters the WPC.

  3. These public IP addresses of the connected networks associated with those SaaS Applications are then to be used to whitelist login access in the SaaS application's security settings.

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

  5. To enforce role-based access control using SSO, the department of the employees needs to be passed as a SAML attribute and mapped to the proper User Groups.

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 two Applications named ‘SalesforceAccess’ and 'ZendeskAccess' to represent the SaaS apps and configured them using their domain names. These Applications were configured for the existing connected networks, which hosted private applications. For this example, assume that it is an AWS VPC configured as a Network named 'AWS_Net.'

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

  3. 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.

  4. 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 connected private network (AWS_Net) associated with the configured Application 'SalesforceAccess.'

    The private network (AWS_Net) will route the traffic to the internet using NAT. The traffic will get the source IP address of the connected network when it reaches Salesforce servers. This makes it appear that the login originated from the private network (AWS_Net) itself.

  5. In order to prevent employees from directly logging into Salesforce without using CloudConnexa, Owen has configured the public IP address range of (AWS_Net) as the only source IP address range from which to allow logins in Salesforce. Refer to 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: