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.
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.
The next entry, app3-saml-sp-okta, looks very similar.
One of the things that is different however is for Header Authentication,
we’re using a Per Request Policy. You can view/configure this by going to
Access Policy>Per Request Policy.
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.
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.
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.
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.
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
