Demo: Access Gateway

This presentation, we're going to have a technical introduction to Okta Access Gateway and how we protect on-prem applications without changing its source code. You can think about these demo application like any other application you have running on-prem. If you have this application protected by OEM or CA, for example, and you access the URL directly, you will see that these application is actually open. Every place I click through, you're going to see that I have access to those places, but the user information is not found over here. There's no URL authorization, there's no user information passed through header attributes to this app. One thing I can do with the gateway is to front-end this application with the gateway URL. We mentioned this will be an intranet IP or something like that. This is what I'm going to front-end with the gateway.

To access the gateway, I can go to my Okta Org and launch the gateway console. I have a separated console here because the gateway works with multitenancy from Okta. For example, in Okta can have a tenant for a different business unit. I can have one tenant for preview and production, I can do any arrangement that I want to. A gateway connects to multiple Okta tenants, and an Okta tenant can connect to multiple gateways. With that, the gateway gives me all the access I need and all the app templates I need to on-prem applications. I can have very complex apps such as ZBS or PeopleSoft, all the way to very simple apps such as header-based applications. Within single application, I get different attributes based on that to connect to the app real fast.

You can get your application going, fully integrated in minutes. This, for example, is a very specific screen to EBS. I don't have an EBS here, so I'm just going to hit cancel. But as you can see, you have an app template for on-prem applications. That application that I have, the demo app, is here already, so let me walk you through the configuration. This is the URL that the application is pointing up to, my reverse proxy's pointing up to, and this is the external URL that will serve that application. This is the way you would typically connect your WebGate, for example, and I have here with Access Gateway. Something really cool Access Gateway is that it fetches attributes from Okta. For example, if I need to assign an application to a new group, I can get the group information straight from Okta from the cloud. It can be groups from AD, from Workday, anything that Okta is connected to will show up over here. I'm assigning this application to everyone and to admins.

Because this application has a different similar session, I can have different timeouts per application. I can have different URLs in log-out pages, authorization other pages. I can define everything per application, which makes it fairly flexible, much more than traditional Win solutions you would use where you have global policies. This attribute page is where I define cousin or any kind of attribute that's coming up from Okta and what header will be served with this attribute. These are all fetched from Okta real time, so if you create cousin attributes in Okta, they will show up over here.

After I'm passing through the attributes, I also have policies, where I can define URLs that are public, secure, protected, et cetera, and I can also define rules. For this I have this rule matching that is basically a logical rejects based, rule. I can write anything I want to, I can write AND's and OR's, I can have nested conditions. It's a very powerful engine, so you can write anything you want over here to get the right protection that you need. For example, here I'm just granting access to the admin group on the secure and granting access to everyone in on public. It is basically public, anyone can access. after I'm done with this, every time I do a change in the gateway, for example, group assignments, it will reflect in my Okta Org. if I refresh over here, you're going to see that I have a new application, and then when I click this application can have single sign on from Okta straight to the app. let me do this real quick. This is a public page, but if I go to secure, you're going to see that I'm already logged in.

All my attributes are here. I don't have any nickname in my user, but I'm going to show you how it looks like if I had one. Let me go back in again, if I go to app straight, this is a public application, but if I hit secure for example, I need to log in. Let me log in with my user [email protected] with my password. This user has a nickname. As you can see if the user has all attributes in Okta the attributes are showed up over here, but the user doesn't have the admin groups. If I head over to the admin page, I'm going to head over to another page. As you can see, authorization works well. Public page I can access, secure page I can access, admin page I cannot. Let me hit log out once again. Go back to my app, and this time I'm going to login with a different user. It is Burns at Okta.com, with my password. And for these users, for this user, I have the admin group here, colon separated. if I go to the admin page, I can see the admin page and the resource over here. as you can see, the gateway handles, authentication, authorization, public pages, etc.

Something very cool about the gateway is that if I have multifactor authentication. For example, I go to app.sudobinbash.com, and see if these users logged over here, and I go to secure. if I have MFA, in this case I have Fido for example, and can do login with its user, in access and application without having to type in password. In this case, they decided to do this with password-less. This system doesn't have any name again, so I have a different experience and if I go to the admin, because it's not an administrator, I cannot have access.