WPA 2 / 802.1X or Captive Portal
With WPA 2 / 802.1X, authentication happens before a user is granted an IP address and allowed on the network, this protects against attacks at upper layers by denying access before a rogue user ever gets on the network. WiFi networks requiring a high level of access security and most VPN networks use WPA 2 / 802.1X based access security.
WPA 2 /802.1X works at Layer 2, the data link layer. In this case, the wireless client is authenticated, the encryption key is derived and the Layer 2 wireless connection between the client and the access point is encrypted. WPA2 supports Extensible Authentication Protocol (EAP) based authentication to prevent access until user authentication is completed
The 802.1X protocol applies to wired and wireless networks. In a wireless network, the 802.1X authentication occurs after the client (end user) has associated to an access point using an 802.11 association method. Wired networks use 802.1X by connecting to a port on an 802.1X enabled switch.
Captive Portal provides a browser–based mechanism for user to login to the network. With Captive Portal, unauthenticated users attempting to access the network are redirected to a Captive Portal web page. Users access to network resources is restricted until they are authenticated via a browser–based login.
Captive Portal is an application–level authentication used primarily with WiFi for hotspot and visitor / guest access networks. With Captive Portal, the user does obtain an IP address on the network prior to authentication; however, their network usage is restricted until they are authenticated via a browser based login.
Captive Portal authenticates users at Layer 3, the network layer. In this case the encryption is typically done at the level of the browser using the HTTPS protocol. Captive Portal authentication is often used in conjunction with a layer 3 VPN, such as an IPSec or SSL VPN, that is used to encrypt the entire layer 3 traffic.
The decision to use WPA 2 / 802.1X or Captive Portal based access security depends on your access network infrastructure and security risk profile. Organizations who’s employees will be using the WLAN or VPN to access corporate applications and resources and cannot risk their network or data being compromised should consider the more secure WPA 2 / 802.1X Layer 2 security approach.
If the primary use of the WiFi network is to access cloud or external resources, for instance in a hotspot or for customer/guest access, then Captive Portal Layer 3 security is an appropriate option.
The Role of RADIUS and AAA
Regardless of which method you choose for enforcing access security on your WiFi AP’s, VPN’s, or other access gateways, authenticating users to a network through client based WPA2 / 802.1X or browser based Captive Portal, Cloudessa RADIUS server provides advanced capabilities for both.
- The RADIUS server orchestrates and manages the interaction between a number of different network elements that need to work collaboratively to manage and secure WiFi Access Point’s and Controllers (AP’s), VPN’s, and other access gateways.
- A centralized RADIUS server receives authentication requests from the WiFi AP’s, controllers, VPN servers, or other access gateway.
- User credentials are then processed against a designated user store, typically Active Directory (AD), or an LDAP or SQL database.
- If a cloud user store such as Google Apps™, SAML or social network is used, Cloudessa RADIUS will create and delete the corresponding RADIUS credentials on the fly
- Authentication is accepted or rejected based on the validity of the provided user account credentials.
- When returning the access accept / reject message to the gateway, the RADIUS server also returns the parameters for the user authorization to network resources. The Authorizations are returned via standard and vendor specific RADIUS attributes, for each user and session, based on which group or groups the user is an authenticated member of (based on the users group assignments in AD, Google Apps or other user store)
- The role of the RADIUS server is essential. Not only does it authenticates the user, but it also communicates back to the gateway WiFi AP or VPN (via RADIUS attributes), the parameters for how that gateway should be configured for that particular user, for that particular session, based on what network group (as defined in AD or Google Apps or other user store) that the user is a member of. Such parameters can include assigning users to particular VLAN’s, setting bandwidth allocation, and dynamically configuring any other configurable policy element of your access gateway.
- RADIUS accounting logs are generated and stored to detail describing the user and the device accessing the network. RADIUS accounting logs can be important for documenting who was on the network, when; and for proving accountability and security compliance within regulated environments such as healthcare, financial services and public access networks.
WiFi access security is dependent on the interoperability between a number of different network components:
- User Device, typically a laptop or smart device running "client" or "supplicant" software or a browser;
- WiFi AP, WiFi Controller, VPN, Firewall or other Access Gateway – The Access Gateway is the access security enforcement point and is the "Authenticator" or "RADIUS Client" that initiates and sends the RADIUS authentication request to the RADIUS server;
- RADIUS Server – IETF Standards based server that handles the authentication, authorization, and accounting for user access;
- User Store – Active Directory, LDAP or SQL database, Google Apps, or other user store where user credentials and user group assignments are stored.
All of these network components must be configured and interoperable to enforce access security.
User Credential Stores
The following user stores and authentication sources are supported:
- Active Directory, LDAP, SQL databases,
- Google Apps
- SAML authentication, for instance Ping Identity, OneLogin, Okta and ADFS
- Social network OAuth–based logins, such as Facebook, Twitter LinkedIn, PayPal.
- Cloudessa internal native user store
- Customer–owned webservices APIs. Examples include hospitality, re– creation, health–care and co–working spaces. In this case Cloudessa will call the external webservices API during authentication