Share This Article
Single Sign-On is a hot topic in the Identity-as-a-Service space. Over the past few years, organizations have been searching for solutions for SSO to web applications. There are a wide variety of approaches to the problem: on-premise SSO-specific solutions, cloud-based SSO-focused solutions, and then broader solutions that integrate directory services and web SSO. Unfortunately, legacy applications have largely been ignored in most organizations. Those legacy applications often leverage the LDAP authentication protocol and not the web-focused SAML protocol. As a result, single sign-on to legacy applications is a forgotten aspect of the identity management problem.
Applications: Reflecting on the Legacy Left Behind
Often, legacy applications are on-premises and have been in existence for some time. These applications tend to be more technical in nature, but that isn’t always the case. While much of the attention is given to hot cloud-based SaaS services, millions of organizations still have a large number of their applications hosted inside their network. A few examples of these applications include: Atlassian Jira, Git, and MySQL. These legacy applications customarily talk over LDAP and not over SAML.
Connecting these legacy applications to an on-premises Microsoft Active Directory (AD) can be tricky. While AD is fundamentally based on LDAP, it has largely focused on Kerberos as the authentication protocol of choice. And, many organizations don’t have an on-premises directory service. These organizations are likely using Google Apps or Microsoft Office 365. In these cases, how do legacy applications connect to a directory service to create that single sign-on capability?
Revealing a Solution to Single Sign-on to Legacy Applications
It starts with a Directory-as-a-Service platform that supports LDAP natively. In the absence of directory service on-premises or with the presence of Google Apps in the cloud, a third-party cloud-based directory service functions as the primary source of credentials. These credentials can then be leveraged in a number of different ways. They can be used for device access (Windows, Mac, and Linux), as WiFi credentials, and for applications access from cloud-based SaaS applications to on-premises legacy ones. The DaaS solution puts out a cloud-hosted LDAP endpoint that legacy applications connect to and authenticate against. The cloud-hosted LDAP knows the core credentials and is able to provide single sign-on access for users.
SSO access to legacy applications should be just as simple as your SSO access to web applications, and it is with modern directory services solutions. Your user will have one set of credentials and the ease of use that they desire. As an IT organization, you will have central control over access to legacy applications with one system.
If you would like to learn more about how Directory-as-a-Service can serve as your SSO solution to legacy applications, drop us a note. Or, feel free to give JumpCloud’s DaaS platform a try for yourself. You’ll be able to not only connect your legacy applications to it, but also your cloud-based ones as well.
