Home Knowledge Base SecureW2 Documentation Implementing WPA2-Enterprise with Dynamic RADIUS and Okta

Implementing WPA2-Enterprise with Dynamic RADIUS and Okta

Introduction

SecureW2 provides a CloudRADIUS solution that lets Okta customers implement 802.1x and certificate-based authentication.

When CloudRADIUS is integrated with Okta, it can communicate with your directory and enforce user policies during authentication. It can dynamically reassign users to different VLANs based on their role changes or deny their access if their risk score is too high.

Below, we lay out how you can integrate CloudRADIUS with your Okta Infrastructure.

Prerequisites

The following are the prerequisites for setting up certificate-based authentication using Okta:

  1. An active Okta account with Super Admin privileges.
  2. A SAML application in Okta with the following permissions:
    1. Okta.groups.read
    2. Okta.users.read

Configuring Okta

You can configure the Okta platform for either Auto or Manual configuration, depending on your requirements. Follow one of the two configurations below as required:

Creating an API Token in Okta for Auto Configuration

CloudRADIUS talks directly with Okta (no LDAP required) using an API. To create an API Token, perform the following steps:

  1. Log in to the Okta Portal.
  2. On the left pane, from the Security menu, select API.
  3. Select the Tokens tab and on the displayed screen, click the Create token button.
  4. In the Create token dialog box, enter a name for the token.
  5. From the API calls made with this token must originate from drop-down list, select the required API source(s).
  6. Click Create token.
  7. On the displayed screen, copy the token value on your console.

    NOTE: Ensure that you save the token value in your console.

Configuring Okta for Manual Lookup

Sometimes, administrators may not have Super Admin Privileges in the Okta Portal to create an API token; follow the steps below to create a service application in the Okta portal. This step requires a role with privileges to create a Service app. 

To create a service app in Okta: 

  1. Log in to the Okta portal. 
  2. Navigate to Applications in the left-side menu.
  3. On the Applications page, click Create App Integration.
  4. In the Create a new app integration pop-up, select API Services. 
  5. Click Next.
  6. In the App Integration name field, enter a name for the service app. 
  7. Click Save. The app is saved and opens to the General tab.

Obtaining Okta Client Id and Key Pair

To obtain the Client Id and Private key: 

  1. Under Client Credentials, copy the Client ID to be used for configuring the core provider in JoinNow. 
  2. Click Edit for the Client Credentials section.
  3. For Client Authentication, check the Public key / Private key option.
  4. Under Public Keys, click Add key.
  5. In the Add a public key pop-up, click Generate new key.
  6. The page refreshes, and a new private key is generated in JSON format. Click Copy to clipboard. Save the acquired content in a text file. This contains both the private key and pubic key.
  7. Click Save.

Granting User Read access to Service Application

  1. Click on the Okta API Scopes tab.
  2. From the listed access grants, select the following roles:
    1. okta.users.read
    2. okta.groups.read.
  3. Click Grant Access to provide access to the service app for reading user and group information.
  4. Click on the Admin roles tab and click on Edit assignments.
  5. From the Role drop-down, select Read-only Administrator.
  6. Click Save Changes.

Disabling Proof of Possession

  1. Click on the General tab and navigate to APPLICATION. Click Edit.
  2. For Proof of Possession, disable the Require Demonstrating Proof of Possession (DPop) header in token requests.
  3. Click Save.
  4. The Client ID and Public Key pair obtained in this section are used in the JoinNow Management Portal for creating the Okta Lookup manually.

Configuring Account Lookup in JoinNow Management Portal

After we’ve created the API Token in Okta, we can configure the policies in the JoinNow Management Portal. These policies validate the certificate each time a Wi-Fi connection request is made, along with the user’s account status in Okta. This ensures that network access is dynamically authorized based on the user’s real-time status in Okta.

Creating a Core Platform

To create a core platform, perform the following steps:

  1. Navigate to Integrations Hub > Core Platforms.
  2. Click Add.
  3. In the Basic section, enter the name of the core provider in the Name field.
  4. In the Description field, enter a suitable description for the core provider.
  5. From the Type drop-down list, select Okta.
  6. Click Save.
  7. The page refreshes and displays the Configuration, Attribute Mapping, and Groups tabs.
  8. Click the Configuration tab.
  9. Under the Configuration section, Okta has two types of configurations available:
      1. Auto – Uses API token to automatically configure lookup with Okta portal. Generating API Token needs Super Admin privileges in the Okta Portal.
        1. In the Provider URL field, enter your Okta organization URL. For example, https://dev-123456.okta.com/.
          NOTE:           Do not use “admin” in the organization URL, as lookup fails.
        2. In the API Token field, enter the token you obtained from the Okta portal (see the Creating an API Token section).
        3. By default, Okta looks up users by the Username attribute. A User Lookup via drop-down list is now available to support customers who want to match users using a custom Email attribute.

          Select one of the following options from the User Lookup via drop-down list:
          1. Username – Looks up the user by username (default)
          2. Email – Looks up the user by email address.

            Figure: Okta Auto Signal Source configuration
        4. Click Validate to check the connection with Okta.
        5. Click Update.
      2.  For Manual Configuration:
          1. Click on the Manual radio button.
          2. In the Provider URL field, enter the Provider URL of your Okta account. For example, https://dev-123456.okta.com/. 
          3. In the Client ID field, enter the client ID obtained from creating a lookup application in Okta. 
          4. For the JWKS Key Pair field, click Choose File. Upload the Key Pair file saved from Okta. Refer to Configuring Okta for Manual Lookup.
          5. Enable DPoP (Demonstrating Proof of Possession): 
            1. Select this checkbox if the Require Demonstrating Proof of Possession (DPoP) header in token requests option is selected under Proof of possession in your Okta Service Application.

              NOTE: Both settings must be enabled together. If this option is selected in Okta but the checkbox is left unchecked in the JoinNow Management Portal (or vice versa), lookups will fail.
            2. If this option is not required, leave the checkbox disabled. JoinNow will continue to use standard bearer access tokens for Okta lookups, which is the default behavior.
          6. By default, Okta looks up users by the Username attribute. A User Lookup via drop-down list is now available to support customers who want to match users using a custom Email attribute.

            Select one of the following options from the User Lookup via drop-down list:
              1. Username – Looks up the user by username (default)
              2. Email – Looks up the user by email address.

                Figure: Okta Manual Signal Source configuration
          7. Click Update.

Configuring Attributes

To add a custom attribute to the core provider, follow the steps below.

  1. Navigate to Integrations Hub > Core Platforms.
  2. Click the Edit link on the core provider created earlier (refer to the Configuring Account Lookup in JoinNow Management Portal section).
  3. Click the Attribute Mapping tab. 
  4. From the Attribute Type drop-down, select the category to display the recommended attributes. The following are the attribute types offered by JoinNow for Okta Lookup: 
    1. User
    2. Custom 
  5. Click Update after selecting the required attributes.

Configuring Groups

Here is where we will map the group attributes we want to use in our network policies. 

  1. Navigate to Integrations Hub > Core Platforms.
  2. Click the Edit link on the core provider created earlier (refer to the Configuring Account Lookup in JoinNow Management Portal section).
  3. Navigate to the Groups tab.
  4. Click Add.
    1. In the Local Group field, enter a name for the group. This group name can be used to configure the Network Policies.
    2. In the Remote Group field, enter the name of your group as it is configured in the Okta portal.
    3. Click Create.

      NOTE: Repeat the process as required for the groups you wish to create network policies around.

Configuring Policies

The following policies need to be configured:

  1. Security Signal Source
  2. Policy Workflow
  3. Default Fallback Role Policy
  4. Network Policy

Configuring a Security Signal Source

Lookup Policies tie our new core provider to domains. Here, we will create a condition that ties our domain to the new core provider we created in the previous section (see the Creating a Core Platform section).

  1. Navigate to Policy Management > Security Signal Sources.
  2. Click Add Security Signal Source.
  3. In the Basic section, enter the name of the security signal source in the Name field.
  4. In the Display Description field, enter a suitable description for the security signal source.
  5. In the Lookup Purpose field, select the RADIUS Authentication checkbox to add the policy to the RADIUS Authentication workflow.
  6. Click Save.
  7. The page refreshes and displays the Conditions and Settings tabs.
  8. Select the Conditions tab.
  9. Under the Conditions section, select the appropriate value from the Identity drop-down list.
  10. Configure Regex to match the values of your devices configured in the Identity field.
  11. Click Update.
  12. Select the Settings tab.
  13. Under the Settings section, from the Provider drop-down list, select the core provider created in the previous section (see the Configuring Account Lookup in JoinNow Management Portal section).
  14. From the Lookup Type drop-down list, select the lookup type: 
    1. Auto: The system automatically uses identity as the Lookup attribute.
    2. Device: The Identity drop-down list is displayed. Select a device identity for lookup.  
    3. User: The Identity drop-down list is displayed. Select a user identity for lookup.
  15. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.
  16. Click the Validate Configuration button to check if the lookup is valid.
  17. On the Validate Configuration pop-up window, in the Enter a valid identity field, enter the identity (user/device) to validate the lookup, and click Validate.
  18. After successful validation, the associated attributes and groups of the core provider are displayed on the Lookup Details prompt. The admin can use this information to configure the network policies and verify the user’s validity.

    NOTE: When the Admin enters an invalid identity on the Validate Configuration pop-up window, the following error message is displayed: “Account lookup failed.”

  19.  Click Update.

Configuring Policy Workflow

The following Policy Workflow policies need to be configured:

  1. Policy Workflow for Network Authentication
  2. Default Fallback Policy Workflow
Policy Workflow for Network Authentication

First, create a role policy for network authentication. This policy will be used by CloudRADIUS Dynamic Policy Workflow to lookup user status at the moment of authentication. Then, CloudRADIUS can dynamically apply Network policies, which you will configure next.

  1. Navigate to Policy Management > Policy Workflows.
  2. Click Add Policy Workflow.
  3. In the Name field, enter the name of the policy workflow.
  4. In the Display Description field, enter a suitable description for the policy workflow.

    NOTE: Ensure that you create a separate policy workflow for authentication.
  5. Click Save.
  6. The page refreshes and displays the Conditions tab.
  7. Select the Conditions tab.
  8. From the Core Provider drop-down list, select the Okta Core Provider created in the previous section (see the Configuring Account Lookup in JoinNow Management Portal section).
  9. Click Update.

Default Fallback Policy Workflow

You may notice that your Policy Workflows have a “DEFAULT FALLBACK ROLE POLICY” after you create an Identity Lookup Provider.

If the Identity lookup fails, this policy allows the user to still authenticate to the network but assigns them a unique role.

This ensures that users don’t experience disconnections if there’s a small hiccup in the connection between Okta and Cloud RADIUS. Your network can remain secure, and you can have those users auto-assigned into a Guest VLAN.

NOTE: DEFAULT FALLBACK ROLE POLICY is by default assigned the DEFAULT NETWORK POLICY.

Configuring Network Policy

A network Policy specifies how CloudRADIUS will authorize access to a particular Policy Workflow.

A typical Network Policy would say something like the following: “If User Role = Staff, authorize access and assign them to VLAN 2.”

You can configure any RADIUS Attribute to be sent to the wireless controller. If you leave the attribute section blank, it will just send an Access Accept message. 

To create and configure the Network Policy, follow the steps below:

  1. Navigate to Policy Management > Network.
  2. Click Add Network Policy.
  3. In the Basic section, in the Name field, enter the name of the network policy.
  4. In the Display Description field, enter a suitable description for the network policy.
  5. Click Save.
  6. The page refreshes and displays the Conditions and Settings tabs.
  7. Select the Conditions tab.
  8. Select Match All or Match Any based on your requirement to set authentication criteria. In the case explained here, we are selecting Match All.
  9. Click Add rule.
  10. Expand Device and select the Device Role option.
  11. Expand Identity and select the Policy Workflow option.
  12. Click Save.
  13. The Device Role and Policy Workflow options appear under the Conditions tab.
  14. From the Device Role drop-down list, select the default device role policy.
  15. From the Policy Workflow Equals drop-down list, select the Policy Workflow you created earlier (refer to the Policy Workflow for Network Authentication section). You can select multiple Policy Workflows to assign to a Network Policy.
    NOTE: You can assign a network policy to multiple user roles.
  16. Select the Settings tab.
  17. Click Add Attribute.
    1. From the Dictionary drop-down list, select an option: Radius: IETF or Custom.
    2. From the Attribute drop-down list, select an option.
    3. In the Value field, enter the appropriate value for the attribute.
    4. Click Save.
  18. Click Update.

NOTE: Repeat the process for all the attributes you want to send to the Policy Workflow.

Conclusion

Dynamic RADIUS will revolutionize the way certificate-based WPA2-Enterprise networks are run. It eliminates all traces of security weaknesses, and the SecureW2 solution helps to manage certificates and users. SecureW2 has affordable options for organizations of all sizes. Click here for further details.

More Okta Explainers
Reseller or MSP? Join our Partner Program