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:

Screen Shot 2022 01 21 at 10.25.39 AM

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.

lr7CET1U9zGH6mAGSzh5xXbDfCBUXC0J1K6oJyUc2KpPdSiPZ7z1wZP7xH5k7ioapwuf44y1fGTOIdD7PLdCAoMhBiAZ1kZgJfjmC0I46DB6J5woA5D TNVzBn9DjwDn3TBREzBd

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.

eQMiEuMAnh3KfoRlKN9UbdTVja 1EsD9wQFbhB 8XO6LvwDbuQZGHugj4gJfsQwujq3eCP1wkRTLdcqsNp9jVYRhWCAx6elVho4lrToQTrSd8 O61k1Ge5tUSAfJ Wj5XCYUW8gN

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.

1WzXu u324i2FHguamA3dvPL 0dfXeX03QdrlcX8BsyrOmctSHj4Edo07ab2eCy1paj2YW1eMKJkQaWUVWu4nBLa76y3vrdDsJ7jOxe at6C lU 2ebbQ ZZoUPNrUd37QXeV Xm

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

jY1sDPsZ ZpFAAWNYOmKu7oZVM SIyPv9655hLsj7YsvHDzN 2CRcMqzlm47uB8tlsAcKlA zYm0cnkAIRQfwSb0LvjHPluGCQwtKxKCMFXRzzduMJmgcoZKpSHJIJdwV6zDB VU

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.

NoxM3DRpyXYnKAcRPITT5qgtAtfWdIWNvsU9 jUIOLOnv9cA6YrkKAtTFeRX1T Ce5UNMz 9yejzp6rvxv01 NHcbhngvGLz5azZY3g3tznJWyCWFKLafp 2 4lpSLtx68RjVUGR

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.