Local Web Authentication Overview
Web authentication is a Layer 3 security solution designed for providing easy and secure guest access to hosts on WLAN with open authentication or appropriate layer 2 security methods. Web authentication allows users to get authenticated through a web browser on a wireless client, with minimal configuration on the client side. It allows users to associate with an open SSID without having to set up a user profile. The host receives an IP address and DNS information from the DHCP server, however cannot access any of the network resources until they authenticate successfully. When the host connects to the guest network, the WLC redirects the host to an authentication web page where the user needs to enter valid credentials. The credentials are authenticated by the WLC or an external authentication server and if authenticated successfully is given full access to the network. Hosts can also be given limited access to particular network resources before authentication for which the pre-authentication ACL functionality needs to be configured.
The following are the different types of web authentication methods:
-
Local Web Authentication (LWA): Configured as Layer 3 security on the controller, the web authentication page and the pre-authentication ACL are locally configured on the controller. The controller intercepts htttp(s) traffic and redirects the client to the internal web page for authentication. The credentials entered by the client on the login page is authenticated by the controller locally or through a RADIUS or LDAP server.
-
External Web Authentication (EWA): Configured as Layer 3 security on the controller, the controller intercepts htttp(s) traffic and redirects the client to the login page hosted on the external web server. The credentials entered by the client on the login page is authenticated by the controller locally or through a RADIUS or LDAP server. The pre-authentication ACL is configured statically on the controller.
-
Central Web Authentication (CWA): Configured mostly as Layer 2 security on the controller, the redirection URL and the pre-authentication ACL reside on ISE and are pushed during layer 2 authentication to the controller. The controller redirects all web traffic from the client to the ISE login page. ISE validates the credentials entered by the client through HTTPS and authenticates the user.
Use the local web authentication feature, known as web authentication proxy, to authenticate end users on host systems that do not run the IEEE 802.1x supplicant.
When a client initiates an HTTP session, local web authentication intercepts ingress HTTP packets from the host and sends an HTML login page to the users. The users enter their credentials, which the local web authentication feature sends to the authentication, authorization, and accounting (AAA) server for authentication.
If authentication succeeds, local web authentication sends a Login-Successful HTML page to the host and applies the access policies returned by the AAA server.
If authentication fails, local web authentication forwards a Login-Fail HTML page to the user, prompting the user to retry the login. If the user exceeds the maximum number of attempts, local web authentication forwards a Login-Expired HTML page to the host, and the user is excluded with the exclusion reason as Web authentication failure.
Note |
You should use either global or named parameter-map under WLAN (for method-type, custom, and redirect) for using the same web authentication methods, such as consent, web consent, and webauth. Global parameter-map is applied by default, if none of the parameter-map is configured under WLAN. |
Note |
The traceback that you receive when webauth client tries to do authentication does not have any performance or behavioral impact. It happens rarely when the context for which FFM replied back to EPM for ACL application is already dequeued (possibly due to timer expiry) and the session becomes ‘unauthorized’. |
Note |
When command authorization is enabled as a part of AAA Authorization configuration through TACACS and the corresponding method list is not configured as a part of the HTTP configuration, WebUI pages will not load any data. However, some wireless feature pages may work as they are privilege based and not command based. |
Based on where the web pages are hosted, the local web authentication can be categorized as follows:
-
Internal—The internal default HTML pages (Login, Success, Fail, and Expire) in the controller are used during the local web authentication.
-
Customized—The customized web pages (Login, Success, Fail, and Expire) are downloaded onto the controller and used during the local web authentication.
-
External—The customized web pages are hosted on the external web server instead of using the in-built or custom web pages.
Based on the various web authentication pages, the types of web authentication are as follows:
-
Webauth—This is a basic web authentication. Herein, the controller presents a policy page with the user name and password. You need to enter the correct credentials to access the network.
-
Consent or web-passthrough—Herein, the controller presents a policy page with the Accept or Deny buttons. You need to click the Accept button to access the network.
-
Webconsent—This is a combination of webauth and consent web authentication types. Herein, the controller presents a policy page with Accept or Deny buttons along with user name or password. You need to enter the correct credentials and click the Accept button to access the network.
Note |
|
Note |
|
Device Roles
With local web authentication, the devices in the network have these specific roles:
-
Client—The device (workstation) that requests access to the network and the controller and responds to requests from the controller. The workstation must be running an HTML browser with Java Script enabled.
-
Authentication server—Authenticates the client. The authentication server validates the identity of the client and notifies the controller that the client is authorized to access the network and the controller services or that the client is denied.
-
Controller—Controls the physical access to the network based on the authentication status of the client. The controller acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client.
Authentication Process
When the page is hosted on the controller, the controller uses its virtual IP (a non-routable IP like 192.0.2.1 typically) to serve the request. If the page is hosted externally, the web redirection sends the client first to the virtual IP, which then sends the user again to the external login page while it adds arguments to the URL, such as the location of the virtual IP. Even when the page is hosted externally, the user submits its credentials to the virtual IP.
When you enable local web authentication, these events occur:
-
The user initiates an HTTP session.
-
The HTTP traffic is intercepted, and authorization is initiated. The controller sends the login page to the user. The user enters a username and password, and the controller sends the entries to the authentication server.
-
If the authentication succeeds, the controller downloads and activates the user’s access policy from the authentication server. The login success page is sent to the user.
-
If the authentication fails, the controller sends the login fail page. The user retries the login. If the maximum number of attempts fails, the controller sends the login expired page, and the host is placed in a watch list. After the watch list times out, the user can retry the authentication process.
-
If authentication server is not available, after the web authentication retries, the client moves to the excluded state and the client receives an Authentication Server is Unavailable page.
-
The controller reauthenticates a client when the host does not respond to an ARP probe on a Layer 2 interface, or when the host does not send any traffic within the idle timeout on a Layer 3 interface.
-
Web authentication sessions can not apply new VLAN as part of the authorization policy, as the client already has been assigned an IP address and you will not be able to change the IP address in the client, in case the VLAN changes.
-
If the terminate action is default, the session is dismantled, and the applied policy is removed.
Note |
Do not use semicolons (;) while configuring username for GUI access. |
Local Web Authentication Banner
With Web Authentication, you can create a default and customized web-browser banners that appears when you log in to the controller.
The banner appears on both the login page and the authentication-result pop-up pages. The default banner messages are as follows:
-
Authentication Successful
-
Authentication Failed
-
Authentication Expired
The Local Web Authentication Banner can be configured as follows:
-
Use the following global configuration command:
Device(config)# parameter map type webauth global Device(config-params-parameter-map)# banner ? file <file-name> text <Banner text> title <Banner title>
The default banner Cisco Systems and Switch host-name Authentication appear on the Login Page. Cisco Systems appears on the authentication result pop-up page.
The banner can be customized as follows:
-
Add a message, such as switch, router, or company name to the banner:
-
New-style mode—Use the following global configuration command:
parameter-map type webauth global
banner text <text>
-
-
Add a logo or text file to the banner:
-
New-style mode—Use the following global configuration command:
parameter-map type webauth global
banner file <filepath>
-
If you do not enable a banner, only the username and password dialog boxes appear in the web authentication login screen, and no banner appears when you log into the switch.
Customized Local Web Authentication
During the local web authentication process, the switch's internal HTTP server hosts four HTML pages to deliver to an authenticating client. The server uses these pages to notify you of these four authentication process states:
-
Login: Your credentials are requested
-
Success: The login was successful
-
Fail: The login failed
-
Expire: The login session has expired because of excessive login failures
Note |
Virtual IP address is mandatory to configure custom web authentication. |
Guidelines
-
You can substitute your own HTML pages for the default internal HTML pages.
-
You can use a logo or specify text in the login, success, failure, and expire web pages.
-
On the banner page, you can specify text in the login page.
-
The pages are in HTML.
-
You must include an HTML redirect command in the success page to access a specific URL.
-
The URL string must be a valid URL (for example, http://www.cisco.com). An incomplete URL might cause page not found or similar errors on a web browser.
-
If you configure web pages for HTTP authentication, they must include the appropriate HTML commands (for example, to set the page time out, to set a hidden password, or to confirm that the same page is not submitted twice). The custom page samples in the webauth bundle are provided with the image and the details of what you can and cannot change.
-
The CLI command to redirect users to a specific URL is not available when the configured login form is enabled. The administrator should ensure that the redirection is configured in the web page.
-
If the CLI command redirecting users to specific URL after authentication occurs is entered and then the command configuring web pages is entered, the CLI command redirecting users to a specific URL does not take effect.
-
Configured web pages can be copied to the switch boot flash or flash.
-
The login page can be on one flash, and the success and failure pages can be another flash (for example, the flash on the active switch or a member switch).
-
You must configure all four pages.
-
All of the logo files (image, flash, audio, video, and so on) that are stored in the system directory (for example, flash, disk0, or disk) and that are displayed on the login page must use web_auth_<filename> as the file name.
-
The configured authentication proxy feature supports both HTTP and SSL.
You can substitute your HTML pages for the default internal HTML pages. You can also specify a URL to which users are redirected after authentication occurs, which replaces the internal Success page.
Redirection URL for Successful Login Guidelines
When configuring a redirection URL for successful login, consider these guidelines:
-
If the custom authentication proxy web pages feature is enabled, the redirection URL feature is disabled and is not available in the CLI. You can perform redirection in the custom-login success page.
-
If the redirection URL feature is enabled, a configured auth-proxy-banner is not used
-
To remove the specification of a redirection URL, use the no form of the command.
-
If the redirection URL is required after the web-based authentication client is successfully authenticated, then the URL string must start with a valid URL (for example, http://) followed by the URL information. If only the URL is given without http://, then the redirection URL on successful authentication might cause page not found or similar errors on a web browser.