The Secret Features of Okta Access Gateway: Part 4: Anonymous Access
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, we’re exploring Okta Access Gateway support for anonymous user access.
The Challenge: Providing access for every user, plus tailored experiences for those who are logged-in
Providing seamless access to users, regardless of their login state, is a critical requirement for some apps.
These apps typically require pages that allow access for users who are, and are not, logged in—aka “anonymous” users. Anonymous users would have a limited view of the page, while logged-in users receive extra options available on their screens.
Here are a couple of examples:
- Anonymous users should only see critical information that must be available, yet doesn’t require a login. Typically, this would be urgent contact information, or a link to recover access, or information the organization wants to make public, such as a link to their benefits page.
- Logged-in users should see all the options related to their roles and departments within the company. This could include, for example, access to specific systems, documents, or compliance training status.
- Anonymous users can navigate through the entire website and are exposed to targeted advertising and promos, geared toward converting them into regular customers.
- Logged-in users receive a tailored experience, based on their shopping habits, such as a list of suggested products.
Example: Amazon website: Anonymous users (left) are pushed to sign in or buy products to establish an account with Amazon, while users logged into Amazon Prime (right) get tailored product suggestions, and are invited to use a service they have previously subscribed to (e.g., Amazon Prime video)
The Solution: Anonymous Access
With OAG, you can support this scenario for your on-prem web apps using the Anonymous Access feature. It allows admins to define and allow access from both logged-in and anonymouse users to specific apps and pages.
What does it look like?
To configure anonymous access to your on-prem app, open your on-prem app settings in OAG, navigate to the Policies page and add an Adaptive Resource, as shown below.
Opening the policies page in OAG
From the Adaptive policy, you can configure a rule that allows access to anonymous resources. This includes the rule name, the page it works for, and an advanced directive to set the login header as "anonymous" when the user is not identified.
OAG configuration for anonymous resources
To prevent bad policies, Access Gateway provides a built-in validation for advanced directives, requiring admins to click the Validation button before a policy is created.
Creating an anonymous resource
This is great for customer identity scenarios like e-commerce, where logged-in users get a tailored experience and anonymous users are funneled into registration pipelines.
With Okta Access Gateway Anonymous Resources, you can define access to specific pages for both logged-in and anonymous users, supporting the kind of advanced access controls typically found only in intranet portals and shopping apps.
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 5: Per-App Session Security, Senior Sales Engineer Bob Burgess explains how to set granular security settings, per application.