By Rajat Bhargava Posted January 29, 2016
There is a great deal of discussion in IT circles about Identity-as-a-Service. Identity management is a critical topic these days. Understandably so, since identities are the keys to the digital kingdom. IT admins are fully aware of the inherent security risks associated with identities. Hackers, too, have figured out that compromised credentials are the fastest path to owning an organization’s critical digital assets. As a result, IT organizations are trying to figure out how to leverage core identities to help control access to the IT resources that their users need. The IT resources we’re referring to can include devices, applications (legacy, on-prem, and cloud), and networks. The challenge, though, is that Identity-as-a-Service has historically been focused on web application single sign-on.
Early SSO and the Creation of IDaaS
The identity and access control infrastructure for any organization is crucial. It really is the foundation for any IT network. As web application single sign-on emerged over the past decade, the identity management environment was pretty straightforward. The core identity provider was generally Microsoft Active Directory, and the environment was virtually all Microsoft Windows. As cloud applications emerged, a category of solutions, which was built on top of the core directory services, also materialized. Since the core directory couldn’t easily talk to web applications, a new category needed to be created. What’s it called? Identity-as-a-Service.
Untangling the Web of Single Sign-on
The trouble with the definition of Identity-as-a-Service is that it has become synonymous with web application single sign-on. Why is that a problem? Today, there’s more to networks than just AD and SSO. There are a number of other components that need to be accounted for. For starters, there’s AWS cloud infrastructure and the prevalence of Macs and Linux devices. Then there’s the fact that WiFi networks are customary, and they require integration with the core identity server. That overall architecture needs to be integrated with a number of IT resources. Additionally, the identity provider needs to work with a variety of device types, cloud and on-premises applications, and networking equipment. This requires the core directory to support an assortment of different protocols, including LDAP, SAML, RADIUS, SSH, REST, and more.
DaaS: Answering the SOS for All-Inclusive SSO
A core directory service delivered as a cloud-based service is the new standard for Identity-as-a-Service. Merely offering web application single sign-on isn’t enough. A SaaS-based identity management service needs to be at the core of an organization, and web SSO is no longer adequate. IT organizations are looking for that central user management system delivered as-a-service.
If you would like to learn more about how Directory-as-a-Service is becoming the new Identity-as-a-Service standard, drop us a note. We’d be happy to discuss why IDaaS needs to be more than just web SSO.