Okta Access Gateway + the LDAP Interface = Lose Your Legacy Servers

1dUkc18URT8UlB7fRU7J3fT7KTrXNYac7oCn8Q lKF7U0kb C 3lqPkhyqggaY8Y9zJ9Ma kaHb42 t MLoKQvX2FkpBb3cHj7v4fE1CRMdZ9BKGNsvMlUhKY7ea37gf271Q jL6

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.

 aQo8tj73Cbcn2gcQ qTgN5cF04vZntTjxGZV Jq AFHbJ3qwv6RVUZIWjcD2oJQxJzBX5Z5vvshibOlQDhj2Erbj61KXY Iks4MyzxC8Gto2rw5hq8YYS4qkFVZDLnViL1MhgXLConceptual Architecture: Even with Cloud identity, some on-prem apps still rely on an LDAP server in addition to SSO.

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.

NTt6lQh4ijBxH5pMjTnO8EddjfIghFySDi4mU15m1ahw6RHGvRxowBvE6hy7s5Wulpn UJjEjtysTZcdVQbJvTm7ZJjRVNNQcz8DwDg7XXerVBAObo9EHmjr92OC7WTgJOwcBNsZOkta LDAP Interface: Available from the Okta Admin Interface

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:

  1. 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.
  2. For SSO, integrate your application with Okta Access Gateway.
  3. 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:

6cfkcl4x2a3yrWGSqvu gVT hGCdYnBirBNNjsYtZe9vFCgPIskg3MbWIjEhexPghwBYxHPIbbXwRczM4wuYQqKgqjU7vBaCbvRfQTy6xhQvbkbpXJbXPnkFs7 IDWOD15 IbO0g

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:

pnEawDqpT2D9BkDYAUyEvkYXGizC6RQMribg48SZMhpR9 Il LTAdymVrylxI6lr5tU3sOv24sk8kPBF2uuPukIQBnYERLVpBOBc4dEXXxfr3udXLSAldSBM5xGusBvkTeO QJeoOkta Identity Cloud, OAG, and the LDAP interface

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!