Okta Access Gateway + the LDAP Interface = Lose Your Legacy Servers
Mark Wilcox, June 18, 2020
At Okta, we love securing access to everything from a single platform. And, as we deeply explored in our previous series, Secret Features of Okta Access Gateway (OAG), that includes on-premises apps. Throughout the series, our specialists demonstrated how OAG and the Okta Platform can secure on-prem web apps in ways you’ve probably never imagined!
And, if you missed it, here’s the skinny: OAG allows you to secure access to on-premises web apps and the hybrid IT using Okta SSO and Adaptive MFA. Click here to learn the basics before diving in!
Introducing… The Secret Sauce of OAG!
But now, we’re covering a new angle. Our specialists wanted to weigh in with how OAG is at its best when paired with the features that make up the Okta platform. In other words, we’re giving you the Secret Sauce! Look for a new recipe each month.
In our first post of the series, Senior OAG Specialist Mark Wilcox explores how OAG works together with the Okta LDAP Interface to eliminate the need for on-premises middleware, databases, and LDAP servers for on-prem identity.
The Challenge: Traditional on-premises web apps require local LDAP servers for authorization
Let me start with a quick history lesson. 25 years ago in Web 1.0, we didn't have many standards. Even basic interoperability features like database drivers didn’t exist. That was also true for storing, authenticating, and authorizing users. New web apps were deployed at scale, each with its own set of credentials, overloading help desks with password resets. Novell eDirectory was the most popular solution, but it was restricted to proprietary protocols.
Back in the day, I published a common pattern to solve this challenge on top of LDAP protocol (Implementing LDAP, Mark Wilcox (1999)). This helped to establish LDAP as a de-facto standard for storing user data. LDAP allowed organizations to have user and authorization data in a single place, available for any 3rd-party solution or programming language, regardless of vendor. (This is one of the many technology innovations to come out of Dallas, TX, including integrated circuits and the frozen margarita machine). LDAP, together with Web Access Management (WAM), provided customers with single sign-on (SSO) access for web applications.
As time passed, however, organizations started replacing WAM with cloud identity solutions like Okta. Today, many organizations still depend on LDAP servers to get additional information for user authorization, as shown below.
Wouldn’t it be nice to eliminate the need for keeping LDAP servers running on-premises and simply leverage data straight from your cloud directory? It’s a much more modern approach.
The Solution: Use OAG with the Okta LDAP Interface
The Okta Identity Cloud has a feature named the LDAP interface, which allows apps to query user data—straight from the cloud via LDAP.
With the LDAP Interface, applications can pull from Okta directly using LDAP instead of querying LDAP servers such as the on-premises options of Oracle Internet Directory (OID) or Active Directory LDS. Along with software, patching, and support maintenance costs, the LDAP Interface helps to eliminate these on-prem servers—and their multiple vendors.
The LDAP Interface works great with any application that uses LDAPv3 or later for querying users and groups. That goes from packaged apps, such as Oracle Business Intelligence Applications (Oracle BI), to custom applications such as Java apps hosted on Oracle WebLogic, IBM WebSphere, Apache Tomcat, and Red Hat JBoss.
What does it look like?
You can leverage the LDAP Interface in three steps:
- Migrate data from your on-premises LDAP server(s) to the Okta Identity Cloud. This can be done in minutes using the Okta LDAP or Active Directory agents, or through direct integration with sources of truth—such as your HR system.
- For SSO, integrate your application with Okta Access Gateway.
- Change your application LDAP settings to point to the Okta LDAP interface address, available from the Okta Admin console.
Once you're done, your application has visibility into data from Okta. Here's an example using Oracle WebLogic:
Example: Weblogic seeing Okta users via the LDAP Interface
When the integration is completed, your application no longer requires an on-premises LDAP server and can leverage OAG for Single Sign-On and Multi-Factor Authentication:
When you pair Okta Access Gateway and the LDAP interface, you have the power to eliminate both WAM and LDAP servers to secure on-premises web apps. And, by the way, these features are native, and do not require you to jump hoops or trick the system just to keep things together.
This wraps our first "recipe" in a new series on how OAG pairs well with other features of the Okta Platform (the secret sauce!). We will keep publishing new recipes here every month. Still, there’s much more to learn. To really dig in, find out What Problems Does Okta Access Gateway Solve, then Meet Your Okta LDAP Expert!