Tutorial: Restrict Login Access to SaaS With Whitelisting and Without Backhauling All Internet Traffic

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.

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.

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.

Owen needs to know the domain names belonging to the SaaS applications. For this example, it is salesforce.com and zendesk.com.

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.

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.

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

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.

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

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.

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.

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.

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.