The Secret Features of Okta Access Gateway: Part 2: On-Prem Data Sources

At Okta, we love to secure access to everything, from cloud apps, to consumer apps, to servers, and infrastructure—from a single platform. And that, of course, includes on-premises apps. In our new series The Secret Features of Okta Access Gateway, we’re going to explore some of the best secret features of Okta Access Gateway (OAG) to secure access to on-prem web apps, at scale.

OAG is a solution to secure access to on-prem web apps and the hybrid IT with Okta SSO and Adaptive MFA. If you want to learn the basics about OAG before diving in, click right here.

Each post in this 5-part series will be delivered by a specialist with strong experience using these secrets in the field. And to help you navigate through all the information, we’re framing the posts based on the following key areas:

In this post, Part 2: On-Prem Data Sources, we will explore OAG’s ability to read and write data from on-premises data sources.

The Challenge: A need to use local data sources to share data and make authorization decisions

Organizations in real life can have identity data in both Okta Identity Cloud and in local data sources.

When organizations adopt Okta, they push as much identity information into the Okta Identity Cloud as possible. This simplifies the management and security of the data, especially if the identity data needs to be synchronized into different apps.

However, some data may not be able to be transferred into Okta Identity Cloud. This might be due to regulatory reasons or to the nature of the data itself— transactional versus user profile data. Yet you want to use that data locally in Okta Access Gateway (OAG), either to authorize access or to send it over to an on-prem app via header variables.

For example, Organization X has a shopping app that requires the last four digits of the user's preferred credit card to be displayed on a profile page. This information currently exists in an Oracle Database and should be passed to the backend app by OAG. However, Organization X doesn't want to keep the credit card data outside of its PCI-DSS certified network, as shown below.

If this is the case and the identity data is needed by OAG to make an authorization decision or to pass the data to a downstream app, there's a potential problem.

The Solution: Provide seamless connection to on-prem data sources

To support organizations with user data scattered on their own network, Okta Access Gateway offers a native connection to on-prem data sources. The connection works for both traditional databases, such as MySQL, MariaDB, Oracle Database, and Microsoft SQL Server, as well as LDAP v3 directories like Oracle Internet Directory, OpenLDAP, and Active Directory.

The data source works for both querying data and for just-in-time provisioning operations:

• Querying data: When a user accesses an app, OAG gets a user identifier from Okta and uses that attribute to get a record in the external data store. This result is then brought back to OAG to validate authorization policies as well as send data to the backend app.
• Just-in-time provisioning: When a user accesses an app, OAG gets a user identifier from Okta, then uses that attribute to search for a record in the external data store. If the record is not found, OAG can run a create statement in the database or LDAP to create the appropriate user record during runtime.

What Does It Look Like?

Local Data-Source: OAG can be connected to one more local LDAP or relational database (aka SQL) data sources. This is done via the OAG Admin Console in the Data Source Configuration section.

The configuration page shows everything you need to connect to the datastore. This includes a section for defining how to find records in the data store, as shown below.

As well as a section to define how to add new records to the data store (if needed).

After the data source is configured, you can use attributes from the external data source in the app configuration for both authorization and transmission to the downstream app. Here's an example with a Job title coming from an internal LDAP.

These attributes can be used by OAG to construct authorization rules and then sent to the proxied application as an HTTP header or HTTP cookie.

With local data-sources, you can secure on-premises apps with Okta and OAG in the most complex of environments. These features are native and do not require you to jump hoops or trick the system just to keep things together.

So, if you want to really dig deep into how Access Gateway works, check out this on-demand webinar—there's a cool demo in it. ;-) And if you liked this post, look out for the other 4 secret features of Okta Access Gateway! In Part 3: Maintenance Mode, our senior consultant, Raj Nadimpalli, shows how OAG's maintenance mode provides users with friendly/actionable error pages when your backend apps are not available.