Boundaries, Geolocation and a Flaw
A recent implementation project of SailPoint’s IdentityNow cloud-based SSO product demonstrated some key conceptual challenges when moving from an on-premises based Single Sign On solution to a cloud-based solution.
Many organizations are migrating their applications to the cloud. They are moving to Office 365, cloud-based CRM solutions, cloud-based document management and storage, cloud-based HR solutions, etc. The benefits of “moving to the cloud” are well known; it reduces the need for each organization to maintain their own complex infrastructure, disaster recovery sites, IT application maintenance, etc…
This migration process will ultimately include migration away from VPN solutions and the Integrated Windows Authentication (IWA) approach to Single Sign On. Less intuitive for many organizations is the realization that the move to the cloud necessitates becoming aware of the geolocation of your users.
If you move to a cloud-based SSO solution, during the time period where you have a mixed environment of on-premises and cloud-based applications, you’ll need to be aware of the public IP address of your VPN users. If your VPN users are being routed through your on-premises network and using on-premises IP addresses, the cloud based SSO solution will treat them as on-premises users. Conversely, if your remote VPN users are leveraging their local IP addresses for internet usage, then the cloud based SSO solution will treat them as off-premises users.
Generally, the standard practice is to require two-factor authentication for off-premises users; so, this distinction will be very important to your end users’ experience.
How can the cloud-based SSO solution determine that the user is on-premises? This is done by defining and entering into the cloud based solution the public IP Address ranges of the on-premises network(s).
All is well so far, and not overly complex. However, a monkey-wrench is thrown into the equation when considering the challenge of users who are using a feature called Split Tunneling with their VPN solution. In standard, simple VPN implementations all traffic for VPN users is routed through the on-premises network. However, some VPN solutions offer a Split Tunneling option. This allows a given session’s network traffic for some applications to be routed through the company’s on-premises network and other application traffic to use the actual laptop/remote device public IP address. Unfortunately, this complicates the cloud-based site’s ability to detect and distinguish between on-premises vs. off-premises users.
The solution is to configure one’s VPN solution to route VPN traffic destined for the cloud-based SSO gateway through the on-premises network. Some VPN vendor solutions can easily do this. The flaw is that others cannot.
The moral of this tale is that organizations must plan ahead. When migrating from an on-premises based infrastructure to a cloud-based infrastructure, one must consider the challenges during the transition period of a mixed environment and the need to now be able to identity the geolocation of one’s users. One of these challenges will be VPN users and how to route their traffic. It will be important, if you are considering migrating to a cloud based SSO solution and your organization is using Split Tunneling, you must ensure that your VPN technology can handle this challenge.