How To Configure SSO With An LDAP Identity Provider

By George Lattimore Posted March 9, 2019


To compensate for the complexity of the identity management market, most organizations try and choose point solutions and get them to work well together. This approach makes a great deal of sense based on how the IAM market has evolved, but is it really the best way forward? With the focus on single sign-on (SSO) for web applications, many IT organizations are trying to figure out how to connect that back to their core directory services. The specific challenge then becomes how to configure SSO with an LDAP identity provider.

How We Got Here

The short answer is that there are a number of resources available to connect leading web application SSO tools back to an LDAP identity provider. For example, JumpCloud can be the bridge between web application SSO solutions such as Oktasup>®, OneLogin™, and Google and a cloud LDAP identity provider.

In order to understand why this is interesting, it is important to go back in time to understand how the market has evolved. From the advent of the LDAP authentication protocol in 1993, a number of identity providers were created to work with it, including two leading ones: Microsoft Active Directory® and OpenLDAP.

Most organizations since have leveraged one of these two for their on-prem resources, and until fairly recently, these identity providers have sufficed. AD would win for Microsoftsup>® Windowssup>®-based environments, while OpenLDAP was more useful for technical situations with Linuxsup>® systems and applications. Between the two, before the impending rise of Macsup>® machines, most organizations could find plenty of adequate runway to secure their office environments.

Evolving Past On-Prem Limitations

As web applications started to become more popular however, identities that were stored within AD or LDAP needed to find a way extend out to those web applications. The result was a bridge solution called web application single sign-on, otherwise known as first-generation IDaaS. The core identity provider—either AD or OpenLDAP—would connect with the SSO solution and subsequently federate identities to the web applications that people needed.

Thus, the need to configure SSO with an LDAP identity provider emerged. Of course, this was done with AD as well. The overarching issue for many IT organizations was that there were multiple solutions in the cloud while one of them—the directory service—was still largely on-prem. Ideally, an organization would be able to completely shift their identity management to the cloud with centralized user management, web application SSO, system management, cloud LDAP & RADIUS servers, multi-factor authentication, and more. This would streamline not only the end user’s workflow, but the admin’s workflow as well, releasing efficiency gains in the process.

Identity Management is Now Cloud-Forward

This is precisely where JumpCloudsup>® comes into play, and one of the core reasons why the next-generation identity provider has taken off in recent years. By allowing identities to be stored in a 100% cloud-based directory, configuring SSO with an LDAP identity provider (JumpCloud) is a breeze. Now, those identities can be seamlessly federated out to the web applications that end users require to get their work done, and admins can save considerable time in managing their access.

If you’d like to hear more details about how to configure SSO with an LDAP identity provider like JumpCloud, send us an email or subscribe to our YouTube channel. Keep in mind that signing up for the platform is free for you and your first 10 users, so go ahead and dive in if you’d like to see the features in action.

George Lattimore

George is a writer at JumpCloud, a central source for authenticating, authorizing, and managing your IT infrastructure through the cloud. With a degree in Marketing and an MS in Public Communications and Technology, George enjoys writing about how the IT landscape is adapting to a diversified field of technology.

Recent Posts