IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

Today we’ll take you through BIG-IP APM’s integration with Okta, a cloud-based identity-as-a-service provider.

The primary use case for this scenario is providing the user authentication through Okta and then Okta providing BIG-IP APM a SAML assertion so that BIG-IP can perform legacy SSO using either Kerberos Constrained Delegation (KCD) or Header Authentication. BIG-IP is the Service Provider (SP) in this SAML transaction.

As we log on to a BIG-IP, you’ll see that we have two policies/application examples.

ok1

Let’s click on the Edit button under Access Policy for app1-saml-sp-okta. This takes us to the Visual Policy Editor (VPE) for the first application. As the chart flows, BIG-IP is consuming the SAML authentication, then storing the SSO credentials and doing a Variable Assign so we know who the user is.

ok2

The next entry, app3-saml-sp-okta, looks very similar.

ok3

One of the things that is different however is for Header Authentication, we’re actually using a Per Request Policy. You can view/configure this by going to Access Policy>Per Request Policy.

ok45

We click Edit (under Access Policy) and here via the flow, the user enters and on every request we’re going to remove the Okta header name, which is arbitrary and doesn’t need to be that value – could be any value you choose. But we want to make sure that no one is able to pad that header into a request. So we’ll remove it and insert the variables BIG-IP receives from Okta. This way the application can consume it and we know who that user is.

ok67

So what does it look like?

First, we’ll log into Okta and in the portal, we see two applications – the Header Auth and Kerberos Auth.

ok89

We’ll test the Header authentication first and see that we’re logged into App1 using Header authentication. Tuser@f5demo.com was the account we logged into with Okta and we see the application has been single-signed into using that credential.

ok9a

Now let’s hit that Kerberos auth application. Here again, we’ve been SSO’d into the application. You may notice that the user looks a bit different here as F5DEMO\tuser since this time we used Kerberos Constrained Delegation. So we’ve obtained a Kerberos ticket from the domain controller for F5DEMO as the user to use. So the username can look a little different but it’s mainly about formatting.

ok9b

BIG-IP is able to consume that SAML assertion from Okta and then use SSO capabilities via Header or Kerberos for legacy applications. Watch Cody Green’s excellent demo of this integration.

ps