By Ryan Squires Posted September 1, 2018
As identity security (or lack thereof) is increasingly in the news, the term Identity Provider (IdP) has been coming up a lot lately in IT circles. But what is an IdP? Is it merely any platform that creates a user identity? Or must it provide a degree of identity management to be a true IdP? With identities at the core of IT security, it’s important that we both understand IdPs and the differences between them. With all that said, what exactly is the definition of Identity Provider?
In the most simple terms, an IdP is a database of user records that allows for authentication and authorization to various IT resources. In practice, it is the source of the username and password combination (could also include SSH keys and other forms of identity such as biometrics), with other user attributes that are stored within a database. IT resources can then leverage the IdP to authenticate user identities, and thus, authorize access. These IT resources can include systems, web applications, or file servers; all of which point toward the IdP as the source of truth for verifying user identities. While it may seem simple from the outset, not all IdPs are created equal, and modern IT realities have made the IdP space much more complex (and dangerous) than it was in the past.
The modern concept of the IdP was created in 1993 with the advent of LDAP (lightweight directory access protocol) by Tim Howes and his team at the University of Michigan. LDAP is a protocol designed for the exchange of information between databases of information (i.e. user attributes from usernames and passwords to addresses and telephone numbers) and systems and applications that need that information. This enables a user system to talk to the LDAP-based “database” and make a request. Via LDAP, the database may verify if a given identity is allowed access to the IT resource. Essentially, if the user is found in the directory, and the credentials provided match, access is granted to whatever that user is authorized to access.
Leveraging LDAP, two new solutions came to market. The first was OpenLDAP™, which began in 1998, and is the open source iteration of the LDAP server. The other was Microsoft® Active Directory® (MAD or AD), which leveraged LDAP and Kerberos as foundational elements alongside their own proprietary protocols which aimed to keep users and IT admins on the Microsoft train. One of the two would go on to have a monopoly, and I’m sure you can guess which one.
Defacto Microsoft IdP Monopoly
Released in 2000, Microsoft Active Directory quickly achieved defacto monopoly status in the directory services space. Since Microsoft had created a large user base of Windows® systems, it was easy for IT admins to manage their all-Windows environments with Active Directory. The Windows domain controller could provide each user with a singular set of credentials that could grant access to everything from their system to their applications (Word, Exchange®), file servers, and the network (likely wired). As a result, IT could effectively manage their entire on-prem, Windows-based network from one centralized solution.
But, today, both of these IdPs are showing their age. For example, while OpenLDAP provides authentication to a variety of legacy applications and on-prem hardware, it requires quite a bit of technical know-how to configure and manage. It is also more focused on technical applications that leverage Linux®, rather than competing solutions from Microsoft® or Apple®.
AD is a more robust, enterprise-grade alternative to OpenLDAP. AD can manage systems, applications, files, and networks, but it is designed to work best for Windows and on-prem networks. Admins using Active Directory in cloud-forward, heterogeneous environment, generally turn to third party solutions to supplement their AD implementation. These “add-ons” come in the form of single sign-on (SSO) solutions, directory extensions, privileged identity management solutions, Mac/Linux/mobile management tools, and more. Of course, each of these one-offs comes with a price tag. But the bigger problem is that they decentralize the management of IT resources. Each additional solution creates integration challenges and management overhead.
OpenLDAP and AD are very different, but they also have a lot in common with one another. They’re both about twenty years old, and it shows. In both cases, IT admins still need to maintain and secure on-prem implementations instead of using their time for higher-value tasks.
A New Definition of Identity Provider
IT is shifting to the cloud. This can be seen in the almost universal adoption of web applications (Salesforce®, G Suite™), cloud infrastructure (AWS®, GCP™, Azure®), and cloud-based file servers (Dropbox™, Box™). Legacy directory services such as OpenLDAP and AD aren’t able to fully manage access to all of this modern infrastructure. On top of it all, new Mac® and Linux systems are entering the enterprise, and given AD’s monopoly, often go unmanaged.
But leaving critical resources unmanaged shouldn’t be an option. This isn’t just because it’s inefficient. All these systems, web apps, file servers and cloud infrastructure represent potential attack vectors. It’s time to take identity seriously.
Thankfully, JumpCloud® Directory-as-a-Service® is here to provide one identity for all the resources that a user needs. This means the cloud directory provides access to legacy applications via LDAP like Jenkins, OpenVPN, and MySQL, on-prem file servers via Samba as well as NAS devices from QNAP, Synology, and FreeNAS, and WiFi networks through RADIUS. In addition to these more legacy, on-prem type implementations, JumpCloud DaaS provides access to a multitude of Software-as-a-Service solutions like Slack, DocuSign®, and BlueJeans as well as cloud infrastructure (AWS, GCP, Azure®). Give JumpCloud DaaS a shot for free today. It’s free forever for the first 10 users. If you want to see it in action, schedule a live demo or visit our YouTube page today.