Okta MFA Workflows

This section covers how ClearPass can work with Okta for different type of MFA workflows like SAML SSO and TACACS+ for both user and device logins

Okta is a cloud-based identity and access management service that helps secure user access with an extra layer of protection beyond just passwords.

Okta supports many MFA methods like:

  • Okta Verify (push notifications, TOTP)

  • SMS or voice call verification

  • Email OTP

  • Security questions

  • WebAuthn (biometric/FIDO2 keys like YubiKey)

  • Google Authenticator and others

While MFA does provide more security than just password, it can also lead to poor user experience if not implemented correctly. Certain workflows are more tolerant of the delays when the user has to access a registered device to respond to the MFA prompt. With respect to ClearPass implementation, the following workflows are MFA friendly and commonly deployed:

  1. Management login to ClearPass using SAML SSO
  2. TACACS+/RADIUS authentication for management login to network devices
  3. Guest login using SAML SSO / Cloud Identity
  4. Operator login to ClearPass guest
  5. VPN authentication

INFO

Using MFA for 802.1X authentication on a wireless network could result in user having to go through MFA every time the device gets disconnected from the wireless. 802.1X supplicants are also sensitive to overall time taken for authentication and hence adding extra factors to the authentication flow could result in increase in timeouts depending upon the level of interaction needed from the end user

Using Okta for SAML SSO

SAML is a web based authentication mechanism used to authenticate and authorize users attempting to login to the network or access applications. Once authenticated, the SAML token is cached by the browser and enables the user to access other SSO enabled webpages without having to re-login. MFA can also be part of the SAML SSO web authentication workflow and the type of MFA method depends on the IDP. Okta supports a wide range of MFA options from push notifications, entering OTP from authenticator apps or even FIDO2 biometrics through Okta verify app.

From a ClearPass perspective, this provides a secure and easy way for users to log into ClearPass and also for users to connect to captive portal based networks. The section below captures the configuration steps to use Okta as IDP for management or operator login to ClearPass.

Okta SAML Setup

On Okta a SAML Application has to be created with ClearPass as the service provider as described below:

  1. Login to Okta Admin console and navigate to Applications > Create App Integration




  1. Select Sign-in method as SAML 2.0 and give a name for the Application




  1. Under SAML Configuration settings, configure the Assertion Consumer Service (ACS) URL and the service provider URL as shown below:

The “Single sign-on URL” would be in the format https://<ClearPass FQDN>/networkservices/saml2/sp/acs

Example:

https://cxcii.arubasecurity.net/networkservices/saml2/sp/acs

The Audience URI (SP Entity ID) would be in the format https://<ClearPass FQDN>/networkservices/saml2/sp

Example:

https://cxcii.arubasecurity.net/networkservices/saml2/sp

INFO

ClearPass fully qualified domain name (FQDN) is used in SAML request to Okta and the response will be sent to the appropriate ACS URL depending on the FQDN in the SAML request. Hence, ensure that each ClearPass node has the FQDN configured under Administration > Server Manager > Server Configuration > Click on server name > FQDN .






  1. Note that if you want to enable SSO for multiple nodes in a cluster, ensure that separate “Single sign-on” URLs with the FQDN of each ClearPass cluster nodes are added to “Other Requestable SSO URLs” field in Okta under SAML App > Configure SAML > Advanced Settings

In this example, there is a two node ClearPass cluster with the following roles:

Publisher: cxcii.arubasecurity.net
Subscriber: cxciii.arubasecurity.net
VIP: cxci.arubasecurity.net

Hence, the other requestable SSO URLs are as follows:

https://cxciii.arubasecurity.net/networkservices/saml2/sp/acs

https://cxci.arubasecurity.net/networkservices/saml2/sp/acs





  1. Use attribute statement to return specific user attributes as part of SAML response

  2. Use Group attribute statement to return names of the groups that the user is member of. To return all the group names, use a regex “.*” as shown below. If you want to filter and return only specific groups, apply the appropriate filter in group statement





The attributes returned from Okta would show up in the “Computed Attributes” and can be used as part of the NAC policy





  1. Once the app is created, navigate to Sign On page for the app and ensure that a user authentication policy is selected and appropriate MFA factors are selected as needed.

  2. Next navigate to the Assignments tab and add groups and users who can be authenticated using SAML SSO

Configuring ClearPass for Okta SSO

In ClearPass, Okta needs to be configured as the IDP and a SAML SSO service must be created for management or operator login as described below:

  1. Once the SAML SSO app has been created on Okta, navigate to the Sign On page, expand the “More Details” section to get the “Sign on URL” and download the Signing Certificate







  1. Navigate to ClearPass, Administration > Certificates > Trust List > Add the signing certificate downloaded from Okta with the usage as SAML







  1. Navigate to ClearPass, Configuration > Identity > Single Sign-On (SSO) > SAML SP and add the Sign On URL copied from Okta as the Identity Provider (IdP) URL




  1. Use the “Enable SSO for” section to select for which application you want to enable SAML SSO for. Note that this is a global configuration and would enable SSO for all the nodes in the cluster. Enabling SSO for “Guest” requires additional configuraton to create a SAML SP weblogin page as described in step #6




  1. Select the Okta signing certificate as the Identity Provider (IdP) Signing certificate as shown below.






  1. If enabling SSO for Guest login, navigate to ClearPass Guest > Configuration > Pages > Web Logins and create a new web login page as shown below with the Pre-Auth check set to “Single Sign-On - SAML Service Provider”




  1. Configure a service to handle SAML SSO authentication by navigating to ClearPass, Configuration > Service Templates & Wizards and select the template “ClearPass Admin SSO Login (SAML SP Service) and configure the service as follows








INFO

The applications selected in the service should match with what was selected at step #4 under Configuration > Identity > Single Sign-On (SSO) > SAML SP

  1. Now that the service has been configured, we need to create role mapping and enforcement policy to assign the approriate enforcement action. A sample enforcement profile is shown below that assigns read only access to users belonging to “HQ Employees” group in Okta while providing admin access to users belonging to “Tech Marketing” group and help desk access to users belonging to “Help Desk” group in Okta.




The enforcement profiles used in this example are:













Okta SSO in action

Example of Okta SSO for guest operator login using push notification





Example of Okta SSO for login to ClearPass Insight using Okta FastPass


Using Okta for Device Logins

Logging into devices and applications can also be secured by using MFA workflows. Typically the authentication protocols used are either RADIUS or TACACS+. ClearPass enables MFA for device logins by forwarding the auth request to Okta RADIUS agent. Okta RADIUS agent then uses API calls to Okta to authenticate the user and evaluate MFA; whether it is by triggering a push notification or evaluating the MFA token within the password attribute. Below is the flow diagram of how the integration works:





Installing and configuring Okta RADIUS Agent

Okta RADIUS agent is a lightweight application that runs as a system service that tunnels communication between on premise system and Okta. It delegates authentication to Okta using single-factor authentication (SFA) or multifactor authentication (MFA). The agent can be installed on windows or linux platforms and supports PAP, EAP-GTC and EAP-TTLS (with PAP as inner method) authentication methods.

These steps describe how to install the Okta RADIUS agent on a windows server:

  1. Login to Okta and download the agent from Settings > Downloads




  1. Run the exe file on the windows server to install the agent.

  2. Enter proxy details if there is a proxy to reach Okta

  3. Enter organization URL which would be Okta URL and sign in using a service account

  4. Allow Access when prompted





  1. The next step is to configure a RADIUS App on Okta. Login to Okta admin console and navigate to Application > Browse App Catalog > Search for RADIUS and add the RADIUS Integration








  1. Configure the RADIUS UDP port as 1812 and enter a shared secret for RADIUS communication between ClearPass and Okta RADIUS Agent




  1. Once the RADIUS App has been installed, navigate to the Sign On page of the app set up the following authentication settings.








  1. For MFA workflows, ensure that a Sign On Policy is applied and multifactor is required for every session




  1. Next navigate to the Assignments tab and add groups and users who can be authenticated using RADIUS Agent

Configuring ClearPass for TACACS+ MFA with Okta

On ClearPass, Okta needs to be configured as a token server so that any incoming TACACS+ request will be sent to Okta as RADIUS.

  1. Add Okta RADIUS Agent as Token server with appropriate authorization source like Active Directory or Okta (over LDAPS). Steps to configure Okta as an LDAPS authentication source is documented here: https://arubanetworking.hpe.com/techdocs/NAC/tech-corner/okta-ldap/




  1. Create a TACACS+ service that uses the token server as authentication source and define the role mapping and enforcement profiles to return appropriate level of access




Device login with Okta MFA

On the network device, ClearPass should be configured as the TACACS+ server. The video below captures how the push notification based MFA user experience looks like.

To trigger a push notification the password has to be entered as password,push

Example: aruba123,push

To use one time token the password has to be entered as password,token

Example: aruba123,635710




Last modified: November 26, 2025 (925ef6c2)