Implementing WPA2-Enteprise with Dynamic RADIUS and Okta

Implementing WPA2-Enteprise with Dynamic RADIUS and Okta

Digital certificates have proven that networks can bolster their security without sacrificing user experience. Though many have dismissed certificate-based authentication in the past, it has become a gold standard for wireless security.

SecureW2 provides a Managed Cloud PKI solution allowing Okta customers to implement 802.1x and certificate-based authentication. This setup makes it easier to configure WPA2-Enterprise Wi-Fi and user authentication for Wi-Fi, VPN, Web Apps, Desktop Logon, etc. Check out our setup guide on how to configure WPA2-Enterprise in Okta.

SecureW2’s PKI is built with a Dynamic RADIUS server that can be configured to communicate with your directory and enforce user policies at the time of authentication. Cloud RADIUS empowers organizations with certificates because it’s the only RADIUS server that can securely communicate with Cloud Identity Providers (IDP). Admins no longer have to reissue brand new certificates in case a user’s policy changes and the system will update immediately.

Below, we lay out how you can integrate SecureW2’s Dynamic RADIUS with your Okta setup.

Create a Web Application

  1. Login to Okta
  2. Navigate to Applications
  3. Click Create New Applications
  4. Select Web as the Platform and click Next
  5. Configure the following settings:Note: Use your unique SecureW2 Organization URL as the Login Redirect URI, followed by /auth/oauth/code.Note: You don’t need to enter in a Base URI.
  6. Click Save.
  7. Scroll down to Client Credentials.
  8. Copy and save the Client ID.
  9. Copy and save the Client Secret.

Okta API Scopes

Lastly, we need to give this application permission to access the data in our Okta directory.

  1. Navigate to Okta API Scopes under the Manage section.
  2. Grant the following API Scopes:
    • Okta.users.read
    • Okta.groups.read

Getting Started

The Getting Started Wizard creates everything you need for 802.1x. It will generate a RADIUS Server, Network Profiles, a Landing Page for Device Onboarding, and all the default network settings you will need for 802.1x.

Note: If you have already configured SecureW2 for your network, you may skip this step.

  1. Navigate to Getting started under the Device Onboarding section.
  2. Configure the following settings:
    • Keep all the settings the same, except:
      • SSID: Change this to the SSID name you wish to authenticate users with.
      • Wireless Vendor: Change this to your Wireless Infrastructure Vendor.
  3. The Getting Started wizard will typically take 60-90 seconds to create everything required, so please be patient before moving on to the next steps.

Create an Identity Lookup Provider

An identity provider (IDP) is the system that proves the identity of a user/device. Creating an IDP in SecureW2 tells the Cloud Connector system how to connect to your Okta user database, verify user credentials, and issue certificates.

During the authentication process, identity lookup validates that a user is active within the organization by checking the identifying information against the existing users in the Identity Provider.

  1. Navigate to Identity Providers in the Identity Management section.
  2. Click Add Identity Provider.
    • Enter a Name.
    • Description is optional.
    • Select Type as:
      • Identity Lookup Provider
        1. OKTA
  3. Click Configuration while still in the Identity Provider edit menu.
    • For Provider URL enter your Okta organization URL.
      • Example: https://dev-123456.okta.com/
    • For Client ID enter in the Client ID that you retrieved from Okta previously.
    • For Client Secret enter in the Client secret you generated in Okta previously and saved in a secure place.
      • After updating the Identity Provider, this secret will not be retrievable, so make sure this is saved in a secure place.
    • Click Update.
  4. Lastly, click Authorize on your new Identity Lookup Provider.
  5. This will test the connection between SecureW2 and your Okta App.
  6. This is a mandatory step, as it grants our application the final authorization to call our Okta API to grant User Info.

Configuring Groups

Lastly, Cloud RADIUS can perform a User Group Lookup so we can create network access policies based off of the Groups a user is in.

  1. Navigate to the Groups tab.
  2. Click Add.
    • Create any name for Local Group.
      • This name will be what shows up later as our ‘Group’ in the SecureW2 Management Portal when we configure policies.
    • In Remote Group enter in the name of your Group as it is configured in Okta.
  3. Click Update.
  4. Repeat as necessary for any Group you wish to create Network Policies around.

 

Configuring Policies

By integrating Dynamic RADIUS with Okta, the RADIUS can segment users and determine access levels for each user based on their stored directory information. Better yet, enforcement occurs at runtime, meaning the changes you make to a user’s permissions will be implemented immediately instead of taking a day or two to complete.

Account Lookup Policy

Lookup Policies are how we tie our new Identity Lookup Provider to domains. Here we will create a condition that ties our domain to the new Identity Lookup Provider we just created in the previous section.

  1. Select Lookup under Policy Management.
  2. Click Add Identity Lookup Policy.
  3. Create a Name and click Save.
  4. Navigate to the Conditions tab.
    • Configure the following settings:
  5. Navigate to the Settings tab
    • Select the Identity Lookup Provider we just created in the previous section.

User Role Policy

User Role Policy for Enrollment

The first User Role Policy we will need to create is one for enrollment. This is what MultiOS will use when end users are enrolling themselves for certificates. MultiOS will not use the OAuth application you previously created in Okta, but instead need to use a separate SAML Application in Okta.

Please refer to one of our SAML Identity Provider configuration guides if you haven’t set this up already. Once you have your SAML IDP, start here:

  1. Add a Role.
  2. Create a Name.
    • Because we need multiple User Roles, specifying this is for Enrollment is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select your Okta SAML Identity Provider.
    • Make sure not to select the Okta OAuth Application we just previously created.
  6. Click Update.

User Role Policy for Network Authentication

Next, we need to create a User Role Policy for Network Authentication. This policy will be used by Cloud RADIUS’ Dynamic Policy Engine to lookup user status at the moment of authentication. Then Cloud RADIUS can dynamically apply Network policies, which we will configure next.

  1. Add a Role.
  2. Create a Name.
    • Because we need multiple User Roles, specifying this is for User Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Okta Identity Lookup Provider that we just created in the previous section.
  6. Click Update.

Group Role Policy for Network Authentication

Lastly, we need to create Role Policies for any Groups that we want to give differentiated network access. We can then leverage Cloud RADIUS’ Dynamic Policy Engine to send unique RADIUS attributes based on the Group users belong to with our Network policies.

  1. Add a Role.
  2. Create a Name.
    • Because we need two User Roles, specifying this is for Group Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Okta Identity Lookup Provider that we just created in the previous section.
  6. Under Groups select the group that we want to apply this Role to.
    • The group names that show up here, are the Local Groups that we configured previously in our Identity Lookup Provider.
  7. Click Update.

DEFAULT FALLBACK ROLE POLICY

You may notice that there is a “DEFAULT FALLBACK ROLE POLICY” in your User Role policies after you create a Identity Lookup Provider.

The purpose of this policy is: If the Identity Lookup fails, allow the user to still authenticate to the network but assign them a unique role.

This ensures that both users don’t experience disconnects if there’s a small hiccup in the connection between Okta and Cloud RADIUS, but 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

Network Policy

The purpose of a Network Policy is to specify how Cloud RADIUS will authorize access to a particular User Role.

A typical Network Policy would say something like: “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 Access Accept. To create and configure the Network Policy, follow the steps below:

  1. Click Network in the Policy Management section.
  2. Click Add Network Policy.
  3. Enter a Name.
  4. Click Save.
  5. Navigate to Conditions.
    • Select the User Role you want assigned this Network Policy.
      • For this guide, it would be the policy you created in the User Role Policy for Network Authentication section.
      • You can select multiple User Roles to assign a Network Policy to.
  6. Navigate to Settings.
    • Click Add Attribute.
      • Select the Attribute you wish to send to the wireless controller.
      • Enter in the Value appropriate for your attribute.
      • Click Update.
    • Repeat as necessary for all the attributes you want to send for your User Role.

Conclusion

Dynamic RADIUS will revolutionize the way certificate-based WPA2-Enterprise networks are run. It eliminates all traces of security weaknesses and makes it easier to manage certificates and users. SecureW2 has affordable options for organizations of all sizes. Click here to see our pricing.