Over the last year or so, I’ve been writing a lot about identity and access management as a service (IDaaS). It’s a win-win. Federation, single sign-on, multi-factor authentication, automated provisioning, and certificate-based authentication bring security and convenience to IT and end users alike.
I also wrote about how about how IDaaS is getting smarter. Machine learning, enterprise mobility management, and other security data can come together with IDaaS, providing a richer context that enables more nuanced and powerful authentication and authorization policies (also known as conditional access).
Most of the conversation about IDaaS has been about using it to enable cloud-based SaaS apps, because that’s where the identity challenges are today.
Identity and security for our on-premises applications have essentially been in place for years. These applications simply rely on our on-premises AD for user directories and authentication, and they benefit from all the things we do to keep our corporate networks secure, like NAC and VPNs.
So when we think of connecting IDaaS to on-premises resources, we think about tasks like syncing our user directories, and syncing password hashes or authenticating users to ADFS (depending on how we choose to set things up). The rest of the time, it’s all about accessing those cloud-based SaaS apps.
However, it doesn’t always have to be this way. Many IDaaS products have proxies or connectors that can get users to on-premises applications, too.
There are many products that do this—here are a few examples that crossed my mind recently: Microsoft Azure AD has an on-premises app proxy (they note that Sharepoint is a top use case), and earlier this fall they announced integration with Ping Identity PingAccess, for apps that use header-based authentication or web access management systems. At Oktane in August, Okta announced support for RADIUS and integration with F5 Networks. In October, VMware announced that Workspace ONE will integrate with F5 for access to Kerberos and header-based applications. And recently I got to know OneLogin, who acquired a web access manager company and can provide access to apps via the RADIUS protocol.
Using modern IDaaS to control access to on-premises applications has several benefits.
First, there’s simply the convenience of consolidating visibility, control, and policies in one place.
More importantly, it means that all of your on-premises applications can be protected by all the modern “smart” authentication techniques and conditional access policies provided by IDaaS, too. (Plus, if you’re using machine learning to figure out what normal and compromised user behavior looks like, you have a larger data set.)
Many of these on-premises connectors and proxies for IDaaS can also provide remote access as an alternative to VPNs. The on-premises applications aren’t actually exposed to the internet—they’re only accessed by users that have already been authenticated and authorized according to policies in the IDaaS platform.
Using IDaaS for on-premises applications also means that you can treat all of your users as remote users, all of the time. This is a concept we’ve talked about for years. With more cloud apps and employees working all over the place, it’s the natural evolution of the corporate network. It’s also much simpler for users—there’s no VPN to worry about, and there’s just one way for them to access all of their cloud and on-premises applications, regardless of whether they’re in the office, at home, or mobile.
Of course this a lot of work that’s not going to happen overnight. And many companies will look at their on-premises apps and see that they’re taken care of for now—it’s the cloud-based apps that are demanding attention these days.
But as you’re thinking about IDaaS to enable your cloud apps (or perhaps as you’re thinking about how your network will evolve), also look to the future and think about how IDaaS could be the way you control access to all of your apps in a few years.