DevTest - OKTA SSO Configuration Guide

Products

Service Virtualization

Issue/Introduction

How to login to IAM, Enterprise Dashboard, and Portal using OKTA User ID?

This useful but not so extensively documented feature has been in the product since 10.5 when Kerberos support was added
The purpose of this guide is to help you familiarize yourself with the concept behind SSO Integration in the Service Virtualization.

Before starting the configuration steps, read about OAuth/OAuth2 concepts:
https://ultimatesecurity.pro/post/okta-oidc/

Environment

DevTest 10.7.2

Resolution

The configuration involves doing things in tandem on OKTA as well as IAM. So, let's get started:

Get a trial account from OKTA. The typical trial period is 30 days
When you log in to your OKTA account, this is how it would look: https://trial-<ID>-admin.okta.com/admin/apps/active
Now Go to IAM. Login as an admin user. Click on 'Identity Providers' from the left side menu.
Note: OKTA and GOOGLE providers have already been configured; otherwise you would see an empty table here.
Let's go ahead and add a new Identity provider. Just click on the 'Add Provider' button on Top-Right and choose the 'OpenID Connection v1.0'
option.
You would be shown the below screen. Give a meaningful Alias and Display Name. The 'Alias' Name would be useful to make one among the
many Identity providers as Default. This will be explained later. The 'Display Name' is mandatory. This will be the name of the button that will
appear in the login Screens. (see second screen shot below). At this point, we will start doing some steps with the OKTA side (Remember
Tandem). Just make sure to copy the value of Redirect URI from the 'Add Identity Provider' screen. We need this value on the OKTA
Side.
Login to your OKTA Account. In this example, it is https://trial-<ID>-admin.okta.com/admin/apps/active
Click on the button 'Create App Integration'
A window pops up. Choose the first option 'OIDC - OpenID Connect'
The Window would expand once you select OIDC. Choose Application Type as 'Web Application'. Click Next
In the next screen, give a name for the APP, lets call it as OKTADEMO. This is the IAM App which is an OAuth Client for OKTA. Just retain the
default settings as shown below. The most important field that binds IAM to this OKTA Application is the Redirect URI. This value comes from
IAM (refer to Step 5). Paste the value of Redirect URI from IAM here. This is VERY VERY Important as OKTA needs to redirect to this URL after
authenticating the SSO User.
The rest of the configuration should be exactly as shown below. Noting more, nothing less.
Save the Application. Once Saved, OKTA would assign a CLIENT ID and generate a CLIENT SECRET. These values need to be copied from
OKTA and saved at IAM Side. Do this carefully.
Along with the ClientID and Client Secret we also need Authorization and Token URLs for the OKTA Application. Thankfully, this can be easily
obtained from invoking the following URL. You need to give the correct clientID value: https://trial-<ID>.okta.com/oauth2/default/.well-known
/openid-configuration?client_id=<client_id>
We are done with all that we need to do on OKTA Side. Let's go to IAM and provide the values from the OKTA Client. (see screenshot above). But for the DYNAMIC values from OKTA, make sure you use the other options as shown below exactly. The scope determines what objects would be
passed from OKTA to IAM upon successful authentication. THIS IS SUPER IMPORTANT as we need this information to create a new user in
IAM (if it doesn't exist). More on OAuth Scope here: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims. Save the screen.
The next step is to define the mappers for the newly added Identity Provider. The mapper is again VERY IMPORTANT as this provides the much-needed roles for the OKTA User who logs into IAM/ED/Portal. By default, there are no mappers defined. Click on 'Create' button to define the mappers. We basically need to define 3 role-maps for the OKTA User. Assuming that the user wants to be able to log in to IAM. ED as well as PORTAL. We will assign 3 roles.
Give a meaningful name for the Mapper. Choose type as 'Hardcoded Role'. There are 2 more mapper types to assign role, but that's for another
day. For now, we keep it simple.
Choose the role as shown below and save it.
Similarly, define 2 more roles. ED-Admin and System Admin, so that the OKTA User can login to IAM, ED as well as Portal. If you forget to create
the mapper, then the OKTA User gets created in IAM without any roles. You would get errors when you try to login to IAM/ED/Portal with OKTA
User.
We are almost set. We just need to tweak the Authentication flow and add 2 clients. Lets tweak the Authentication flow as shown below for 'First
Broker Login'. Remember, this is the "First Login Flow" that we chose while defining the Identity Provider (Step 8). FOLLOW THE SETTINGS
PRECISELY AS SHOWN BELOW:
Similarly, choose the "Browser" Flow Values PRECISELY as shown below:
We are done with adding OKTA SSO For IAM. Yes, all the changes done above will only Enable SSO for IAM Login. Let's see how would IAM
look like now:
No need to restart IAM service. A new button with horrible style elements would appear. The text on the button says 'Okta Demo Login' which is
nothing but the Display Name of your OAuth Provider. If not given, then the button text would be just the alias name (Refer Step #8)
Just click on this button, and you would see OKTA Login page come up. Login with your Okta ID and authenticate yourself. Notice the OIDC
Provide Name OKTADEMO appears on the Okta Login screen. Once successfully authenticated, OKTA Redirects to the IAM Application.