Web Authentication Scenarios
There are a number of reasons that a company may choose to implement a WebAuth strategy. One of the most common reasons is to provide Internet access to visitors (also known as guests), as detailed in Chapter 13, “Guest Services.” In addition, as newer versions of ISE come out, many companies are looking to add interactive logins to capture usernames and passwords as additional credentials to certificate-based authentication (think two-factor authentication).
The end user is presented with a web portal to input a username and password. The credentials are then sent from the authenticator to ISE in a standard RADIUS Access-Request packet. So, in a very similar fashion to what occurs with MAC Authentication Bypass (MAB), the switch sends the request for the endpoint, and the endpoint itself does not participate in authentication. Figure 12-1 illustrates the WebAuth concept.
)
The credential that gets submitted through the WebAuth page could be the Active Directory credentials of an employee. The credentials could be guest credentials for someone who is only temporarily allowed to have Internet access (and no other access). The use of WebAuth is really not limited to any specific type of user account.
Keep in mind that WebAuth is only an effective authentication method for a device that has an interactive user. In other words, it would not make sense to try to use WebAuth for a printer as there would be no user to interact with the web portal, enter credentials, and click Submit.
Like MAB, WebAuth is not a standard. There are multiple ways to perform WebAuth, with benefits and downsides to each one.
Local Web Authentication (LWA)
Local Web Authentication (LWA) is the original WebAuth. With LWA, the authenticator redirects web browser traffic to a locally hosted web portal where a user can enter a username and password.
The credentials are submitted through the switch or wireless controller, which sends the RADIUS Access-Request to the authentication server, using the username and password from the web portal’s form. It is key to remember that any time the switch is sending the credentials for the user, it is considered Local Web Authentication.
On a Cisco Catalyst switch, the locally hosted web pages are not very customizable. Many companies require that web portals be customized to match the corporate branding. For those companies, traditional LWA is not usually an acceptable solution—at least not for WebAuth with wired connections.
In addition, when using LWA with Cisco switches, there is no native support for advanced services such as the following:
▪ Acceptable use policy acceptance pages
▪ Client provisioning
▪ Password-changing capabilities
▪ Self-registration
▪ Device registration
▪ BYOD onboarding
For advanced capabilities like these, a company truly needs to consider using Centralized Web Authentication.
Centralized Web Authentication (CWA)
Cisco ISE uses Centralized Web Authentication (CWA) almost exclusively. While Cisco ISE is capable of supporting LWA methods, those methods are typically reserved for non-Cisco network devices.
Like other forms of Web Auth, CWA is only for interactive users with web browsers, who need to manually enter usernames and passwords.
Change of Authorization (CoA) works fully with CWA, which contributes to support for all the authorization results, such as ACL and VLAN authorization. Keep in mind that any time you change VLANs on an endpoint, the endpoint must be able to detect the VLAN change and trigger an IP address renewal. With 802.1X, the supplicant takes care of the VLAN change detection and address renewal. However, when using WebAuth, a supplicant does not typically exist on the endpoint. Therefore, the DHCP scope length must be set to renew the address quickly, or the portal must use an ActiveX or Java applet to handle the renewal of the IP address after the VLAN assignment, which is not a popular option due to the security concerns related to using Java or ActiveX applets.
CWA also supports advanced services such as the following:
▪ Client provisioning
▪ Posture assessments
▪ Acceptable use policies (AUPs)
▪ Password changing
▪ Self-registration
▪ Device registration
▪ BYOD onboarding
As described in Chapter 4, a switch or wireless controller only sees MAB, and the rest is handled on the authentication server (ISE). Figure 12-2 shows the MAB occurring with a redirection to the centralized portal, and Figure 12-3 shows how the switch still sees only a MAB request, with ISE maintaining the user authentication.
)
)
The following steps detail what occurs in Figures 12-2 and 12-3:
Step 1. The endpoint entering the network does not have a supplicant.
Step 2. The authenticator performs MAB, sending the RADIUS Access-Request to Cisco ISE (the authentication server).
Step 3. The authentication server (ISE) sends the RADIUS result, including a URL redirection, to the centralized portal on the ISE server.
Step 4. The end user enters credentials into the centralized portal. Unlike the LWA options, the credentials are never sent to the switch; instead, they are stored within the ISE session directory and tied together with the MAB coming from the switch.
Step 5. ISE sends a reauthentication Change of Authorization (CoA-reauth) to the switch. This causes the switch to send a new MAB request with the same SessionID to ISE, and it is processed.
Step 6. ISE sends the final authorization result to the switch for the end user.
CWA and the URL-redirection capability in the switches and wireless devices are the basis for many of the other solutions in ISE, including Device Registration WebAuth, BYOD onboarding, MDM onboarding, and posture assessment.