Central Web Authentication

Central web authentication

A central web authentication is a wireless security mechanism that

  • delegates the user login webpage and credential processing to a centralized authentication server such as Cisco Identity Services Engine (Cisco ISE)

  • initiates user redirection and authentication at Layer 2, often in combination with MAC filtering or 802.1X authentication, and

  • uses RADIUS server attributes to instruct network controllers to redirect web traffic to the authentication portal, streamlining access and reducing delays.

  • ISE (Identity Services Engine): Cisco’s centralized network access policy platform that delivers authentication, authorization, accounting, and guest access functionality.

  • ACL (Access control list): A set of rules used to control network traffic and enforce security policies, determining which clients can access which network resources.

  • Change of Authorization (CoA): A mechanism to reapply or update authorization parameters dynamically without requiring a new login.

Comparison with other authentication methods

Central web authentication (CWA) enables centralized management of web-based access for wireless clients by utilizing a dedicated authentication portal (typically ISE). The primary distinction from traditional (local) web authentication is that core security and redirection functions are performed at Layer 2 (data link), in conjunction with authentication mechanisms such as MAC filtering or dot1x. In CWA, the RADIUS server provides special attributes directing the controller to redirect web traffic appropriately, thereby triggering portal-based login. This process streamlines authentication, reduces delays, and enhances consistent policy enforcement.

There are multiple methods of web authentication used in wireless environments.

  • Local web authentication (LWA): Configured as Layer 3 security on the controller. The web authentication page and pre-authentication access control list (ACL) are locally configured on the controller. The controller intercepts HTTP(S) traffic from the client and redirects the client to an internal web page for authentication. Credentials are authenticated by the controller locally or through a RADIUS or LDAP server.

  • External web authentication (EWA): Also configured as Layer 3 security on the controller. The controller intercepts HTTP(S) traffic and redirects the client to a login page hosted on an external web server. Credentials are authenticated by the controller locally or through a RADIUS or LDAP server. The pre-authentication ACL is statically configured on the controller.

  • Central web authentication (CWA): Typically configured as Layer 2 security, with the redirection URL and pre-authentication ACL residing on ISE. During Layer 2 authentication, ISE pushes the redirection attributes to the controller. The controller redirects all web traffic from the client to the ISE login page. ISE then validates the credentials entered by the client through HTTPS and authenticates the user.

Table 1. Difference from other authentication types

Method

Layer

Portal

Credential processing

Key attributes

Local Web Authentication

Layer 3

Controller

Locally or through RADIUS/LDAP

Controller intercepts traffic

External Web Authentication

Layer 3

External Server

Locally or through RADIUS/LDAP

Static ACLs, external portal

Central Web Authentication

Layer 2

ISE

Through ISE (HTTPS)

ISE pushes ACL, redirection

Analogy: concert tickets

Imagine a concert venue with several ways to check tickets and admit guests. You can have ticket booths at every entrance (local authentication), ticket checkers who send guests to a special desk outside (external authentication), or one main VIP booth at the heart of the venue that handles everyone’s tickets and access (central authentication). Let’s use this concert analogy to understand central web authentication and other methods.

At your concert venue, central web authentication (CWA) is what happens when, instead of letting every entrance or gate have their own ticket booth, you create one exclusive VIP booth—like Cisco’s ISE—that manages all ticketing for everyone. Instead of waiting until a guest actually tries to enter through a particular door (the way local booth might do), the venue’s security starts checking guests' tickets as soon as they enter the red carpet. The VIP booth can give the gatekeepers special instructions: “If you don’t recognize someone’s ticket, redirect them straight to me!” This means the main ticketing process is handled efficiently and quickly by one central authority.

Let’s look at all the ticketing strategies you could use at your concert:

Local Ticket Booth (Local Web Authentication, LWA): Every entrance has its own mini ticket booth and rules. Guards at the door check tickets and can ask guests for their info. Ticket validation is handled locally at each gate, sometimes via a backstage manager or external system.

External Ticket Desk (External Web Authentication, EWA): Instead of ticket checks at the gate, guests are sent to a desk outside the stadium. The desk is run by another company. The security at the entrance gates redirects guests and the validation can still interact with the backstage manager if needed. Rules for who gets through are set upfront.

VIP Central Ticket Booth (Central Web Authentication, CWA): The gates just check basic details (like guest’s wristband color), and anyone who isn’t recognized is sent straight to the main VIP booth (ISE) to have their ticket or credentials checked and get access granted for the whole event.

Prerequisites for Central Web Authentication

  • Cisco Identity Services Engine (ISE)

How to Configure ISE

To configure ISE, proceed as follows:

  1. Create an authorization profile.

  2. Create an authentication rule.

  3. Create an authorization rule.

Creating an Authorization Profile

Procedure

Step 1

Click Policy, and click Policy Elements.

Step 2

Click Results.

Step 3

Expand Authorization, and click Authorization Profiles.

Step 4

Click Add to create a new authorization profile for central webauth.

Step 5

In the Name field, enter a name for the profile. For example, CentralWebauth.

Step 6

Choose ACCESS_ACCEPT from the Access Type drop-down list.

Step 7

Check the Web Redirection (CWA, MDM, NSP, CPP) check box, and choose Centralized Web Auth from the drop-down list.

Step 8

In the ACL field, enter the name of the ACL that defines the traffic to be redirected. For example, redirect.

Step 9

In the Value field, choose the default or customized values.

The Value attribute defines whether the ISE sees the default or a custom web portal that the ISE admin created.

Step 10

Click Save.

Creating an Authentication Rule

Follow the procedure given below to use the authentication profile and create the authentication rule:

Procedure

Step 1

In the Policy > Authentication page, click Authentication.

Step 2

Enter a name for your authentication rule. For example, MAB.

Step 3

In the If condition field, select the plus (+) icon.

Step 4

Choose Compound condition, and choose Wireless_MAB.

Step 5

Click the arrow located next to and ... in order to expand the rule further.

Step 6

Click the + icon in the Identity Source field, and choose Internal endpoints.

Step 7

Choose Continue from the 'If user not found' drop-down list.

This option allows a device to be authenticated even if its MAC address is not known.

Step 8

Click Save.

Creating an Authorization Rule

You can configure many rules in the authorization policy. The MAC not known rule is configured in this section:

Procedure

Step 1

Click Policy > Authorization.

Step 2

In the Rule Name field, enter a name. For example: Mac not known.

Step 3

In the Conditions field, click the plus (+) icon.

Step 4

Choose Compound Conditions, and choose Wireless_MAB.

Step 5

From the settings icon, select Add Attribute/Value from the options.

Step 6

In the Description field, choose Network Access > AuthenticationStatus as the attribute from the drop-down list.

Step 7

Choose the Equals operator.

Step 8

From the right-hand field, choose UnknownUser.

Step 9

In the Permissions field, choose the authorization profile name that you had created earlier.

The ISE continues even though the user (or MAC) is not known.

Unknown users are now presented with the Login page. However, once they enter their credentials, they are presented again with an authentication request on the ISE; therefore, another rule must be configured with a condition that is met if the user is a guest user. For example, if UseridentityGroup Equals Guest is used then it is assumed that all guests belong to this group.

Step 10

In the Conditions field, click the plus (+) icon.

Step 11

Choose Compound Conditions, and choose to create a new condition.

The new rule must come before the MAC not known rule.

Step 12

From the settings icon, select Add Attribute/Value from the options.

Step 13

In the Description field, choose Network Access > UseCase as the attribute from the drop-down list.

Step 14

Choose the Equals operator.

Step 15

From the right-hand field, choose GuestFlow.

Step 16

In the Permissions field, click the plus (+) icon to select a result for your rule.

You can choose Standard > PermitAccess option or create a custom profile to return the attributes that you like.

When the user is authorized on the login page, the ISE triggers a COA that results in the restart of Layer 2 authentication. When the user is identified as a guest user, the user is authorized.

How to Configure Central Web Authentication on the Controller

To configure central web authentication on the controller, proceed as follows:

  1. Configure WLAN.

  2. Configure policy profile.

  3. Configure redirect ACL.

  4. Configure AAA for central web authentication.

  5. Configure redirect ACL in Flex profile.

Configure WLAN (GUI)

Set up a new WLAN on your wireless controller using the GUI.

Before you begin

You need to enable MAC filtering for Layer 2 authentication to download the redirect URL and ACL.

Procedure

Step 1

Choose Configuration > Tags & Profiles > WLANs.

Step 2

In the WLANs window, click the name of the WLAN or click Add to create a new one.

The Add/Edit WLAN window is displayed.

Step 3

In the Add/Edit WLAN window, click the General tab to configure the following parameters.

  • In the Profile Name field, enter or edit the name of the profile.

  • In the SSID field, enter or edit the SSID name.

    The SSID name is alphanumeric, and up to 32 characters in length.

  • In the WLAN ID field, enter or edit the ID number. The valid range is between one and 512.

  • Select the 802.11 radio band from the Radio Policy drop-down list.

  • Using the Broadcast SSID toggle button, change the status to either Enabled or Disabled.

  • Using the Status toggle button, change the status to either Enabled or Disabled.

Step 4

Click the Security tab, and then select the Layer 2 tab to configure the following parameters:

  • Select None from the Layer 2 Security Mode drop-down list. This setting disables Layer 2 security.

  • Enter the Reassociation Timeout value, in seconds. This is the time a fast transition reassociation times out.

  • Check the Over the DS check box to enable Fast Transition over a distributed system.

  • Choose OWE. Opportunistic Wireless Encryption (OWE) provides data confidentiality with encryption over the air between an AP radio and a wireless client. OWE Transition Mode ensures backwards compatibility.

  • Choose Fast Transition (802.11r), the IEEE standard for fast roaming. This standard allows the initial handshake with a new AP to occur before the client roams to the target AP. This method is called Fast Transition.

  • Check the check box to enable MAC filtering in the WLAN.

Step 5

Click Save & Apply to Device.

Configuring WLAN (CLI)

Configure WLAN using commands.

Note

You need to enable MAC filtering for Layer 2 authentication to download the redirect URL and ACL.

After completing the WLAN configuration, if the changes are not pushed to all the APs, the following syslog message appears:

2021/01/06 16:20:00.597927186 {wncd_x_R0-4}{1}: [wlanmgr-db] [20583]: UUID: 0, ra: 0, TID: 0 (note): Unable to push WLAN config changes to all APs, cleanup required for WlanId: 2, profile: wlan1 state: Delete pending

If the above mentioned syslog message appears for more than six minutes, reload the controller.

If the controller does not reload and still the syslog message appears, then collect the archive logs, wncd core file, and raise a case by clicking the following link: Support Case Manager.

Procedure

  Command or Action Purpose

Step 1

wlan wlan-name wlan-id SSID-name

Example:

Device(config)# wlan wlanProfileName 1 ngwcSSID

Enters the WLAN configuration sub-mode.

wlan-name is the name of the configured WLAN.

wlan-id is the wireless LAN identifier. The range is 1 to 512.

SSID-name is the SSID name which can contain 32 alphanumeric characters.

Note

 

If you have already configured this command, enter wlan wlan-name command.

Step 2

mac-filtering [name]

Example:

Device(config-wlan)# mac-filtering name

Enables MAC filtering on a WLAN.

Note

 

While configuring mac-filtering the default authentication list is considered, if the authentication list is not configured earlier.

Step 3

no security wpa

Example:

Device(config-wlan)# no security wpa

Disable WPA security.

Step 4

no shutdown

Example:

Device(config-wlan)# no shutdown

Enables the WLAN.

Step 5

end

Example:

Device(config-wlan)# end

Returns to privileged EXEC mode.

Example

Device# config terminal
Device(config)# wlan wlanProfileName 1 ngwcSSID
Device(config-wlan)# mac-filtering default
Device(config-wlan)# no security wpa
Device(config-wlan)# no shutdown
Device(config-wlan)# end

Configuring Policy Profile (CLI)

Configure Policy Profile using commands.

Note

You need a AAA override to apply policies coming from the AAA or ISE servers. When a redirect URL and redirect ACL is received from the ISE server, NAC is used to trigger the Central Web Authentication (CWA).

Both NAC and AAA override must be available in the policy profile to which the client is being associated.

The default policy profile is associated to an AP, if the AP is not associated to any other policy profiles.

CWA clients may experience issues with VLAN assignment during the final RADIUS access-accept following successful authentication.

Procedure

  Command or Action Purpose

Step 1

wireless profile policy default-policy-profile

Example:

Device(config)# wireless profile policy default-policy-profile

Sets the policy profile.

Step 2

vlan vlan-id

Example:

Device(config-wireless-policy)# vlan 41

Maps the VLAN to a policy profile. If vlan-id is not specified, the default native vlan 1 is applied. The valid range for vlan-id is 1 to 4096.

Management VLAN is applied if no VLAN is configured on the policy profile.

Step 3

aaa-override

Example:

Device(config-wireless-policy)# aaa-override

Configures AAA override to apply policies coming from the AAA or ISE servers.

Step 4

nac

Example:

Device(config-wireless-policy)# nac

Configures Network Access Control in the policy profile. NAC is used to trigger the Central Web Authentication (CWA).

Step 5

no shutdown

Example:

Device(config-wireless-policy)# no shutdown

Enables the WLAN.

Step 6

end

Example:

Device(config-wireless-policy)# end

Returns to privileged EXEC mode.

Example

Device# configure terminal
Device(config)# wireless profile policy default-policy-profile
Device(config-wireless-policy)# vlan 41
Device(config-wireless-policy)# aaa-override
Device(config-wireless-policy)# nac
Device(config-wireless-policy)# no shutdown
Device(config-wireless-policy)# end

Configuring a Policy Profile (GUI)

Procedure

Step 1

Choose Configuration > Tags & Profiles > Policy.

Step 2

On the Policy Profile page, click Add.

Step 3

In the Add Policy Profile window, in General Tab, enter a name and description for the policy profile.

Step 4

To enable the policy profile, set Status as Enabled.

Step 5

Use the slider to enable or disable Passive Client and Encrypted Traffic Analytics.

Step 6

(Optional) In the CTS Policy section, choose the appropriate status for the following:

  • Inline Tagging—a transport mechanism using which a controller embedded wireless controller or access point understands the source SGT.

  • SGACL Enforcement

Step 7

Specify a default SGT. The valid range is from 2 to 65519.

Step 8

In the WLAN Switching Policy section, choose the following, as required:

  • Central Switching

  • Central Authentication

  • Central DHCP

  • Central Association Enable

  • Flex NAT/PAT

Step 9

Click Save & Apply to Device.

Creating Redirect ACL

The redirect ACL is a punt ACL that needs to be predefined on the controller (or the AP in case of FlexConnect local switching): the AAA server returns the name of the ACL and not its definition. The redirect ACL defines traffic (matching “deny”statements, as it denies redirection for it) that will be allowed through on the data plane and traffic (matching “permit” statements) that will be sent to the control plane towards the CPU for further processing (that is, the web interception and redirection in this case). The ACL has implicit (that is, the invisible) statements allowing DHCP and DNS traffic towards all IPs, just like it is the case with LWA. It also ends with a statement that a security ACL implicit deny.

Procedure

  Command or Action Purpose

Step 1

ip access-list extended redirect

Example:

Device(config)# ip access-list extended redirect

The HTTP and HTTPS browsing does not work without authentication (per the other ACL) as ISE is configured to use a redirect ACL (named redirect).

Step 2

deny ip any host ISE-IP-add

Example:

Device(config)# deny ip any host 123.123.134.112

Allows traffic to ISE and all other traffic is blocked.

Step 3

deny ip host ISE-IP-add any

Example:

Device(config)# deny ip host 123.123.134.112 any

Allows traffic to ISE and all other traffic is blocked.

Note

 

This ACL is applicable for both local and flex mode.

Step 4

permit TCP any any eq web address/port-number

Example:

In case of HTTP:
Device(config)# permit TCP any any eq www

Device(config)# permit TCP any any eq 80

Example:

In case of HTTPS:
Device(config)# permit TCP any any eq 443

Redirects all HTTP or HTTPS access to the ISE login page. port-number 80 is used for HTTP and port-number 443 is used for HTTPS.

For the ACE to allow traffic to ISE, ISE should be configured above the HTTP/HTTPS ACE.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring AAA for Central Web Authentication

Procedure

  Command or Action Purpose

Step 1

aaa server radius dynamic-author

Example:

Device(config)# aaa server radius dynamic-author

Configures the Change of Authorization (CoA) on the controller.

Step 2

client ISE-IP-add server-key radius-shared-secret

Example:

Device(config-locsvr-da-radius)# client 123.123.134.112 server-key 
0 SECRET

Specifies a RADIUS client and the RADIUS key to be shared between a device and a RADIUS client.

ISE-IP-add is the IP address of the RADIUS client.

server-key is the radius client server-key.

radius-shared-secret covers the following:

  • 0—Specifies unencrypted key.

  • 6—Specifies encrypted key.

  • 7—Specifies HIDDEN key.

  • Word—Unencrypted (cleartext) server key.

The RADIUS shared secret should not exceed 240 characters while configuring WSMA data in GUI.

Note

 

All these steps work only if the AAA configuration is in place. See the Configuring AAA Authentication for details.

Example

Device# config terminal
Device(config)# aaa server radius dynamic-author
Device(config-locsvr-da-radius)# client 123.123.134.112 server-key 0 SECRET
Device(config-locsvr-da-radius)# end

Configuring Redirect ACL in Flex Profile (GUI)

The redirect ACL definition must be sent to the access point in the FlexConnect profile. For this, the redirect ACL associated with an AP must be configured in the FlexConnect profile where the client is hosted. If an access point is not configured with any of the FlexConnect profiles, the default FlexConnect profile is associated with it.

Procedure

Step 1

Choose Configuration > Tags & Profiles > Flex.

Step 2

On the Flex Profile page, click the name of the FlexConnect profile or click Add to create a new FlexConnect profile.

Step 3

In the Add/Edit Flex Profile window that is displayed, click the Policy ACL tab.

Step 4

Click Add to map an ACL to the FlexConnect profile.

Step 5

Choose the ACL name, enable central web authentication, and specify the preauthentication URL filter.

Step 6

Click Save.

Step 7

Click Update & Apply to Device.

Configuring Redirect ACL in Flex Profile (CLI)

The redirect ACL definition must be sent to the access point in the Flex profile. For this, the redirect ACL associated to an AP must be configured in the Flex profile where the client is being hosted. If an access point is not configured with any of the Flex profiles, the default Flex profile is associated with it.


Note

When the ACL is pushed down to the APs, the permission must change from deny to permit or vice-versa. This change does not occur if the ACL contains an object group, causing the ACL not to be fully translated, which may cause the redirection to fail.

Procedure

  Command or Action Purpose

Step 1

wireless profile flex default-flex-profile

Example:

Device(config)# wireless profile flex default-flex-profile

Creates a new flex policy. The default flex profile name is default-flex-profile.

Step 2

acl-policy acl policy name

Example:

Device(config-wireless-flex-profile)# acl-policy acl1

Configures ACL policy.

Step 3

central-webauth

Example:

Device(config-wireless-flex-profile-acl)# central-webauth

Configures central web authentication.

Step 4

end

Example:

Device(config-wireless-flex-profile-acl)# end

Returns to privileged EXEC mode.

Troubleshooting Central Web Authentication

Init-State timer running out

Problem Issue: The client devices are deauthenticated by the controller if users fail to enter their credentials in a limited time interval. The clients are deauthenticated after three times the time configured for the init-state timeout in the controller.

Problem Explanation: This is the expected functionality as the init-state timeout is not directly applicable for central web authentication; instead, it is the reap timer’s value which is three times the init-state time plus five seconds (3*init-state timeout + 5) that determines the time interval in seconds for client deauthentication. For example, if you have configured the init-state timeout as 10 seconds, then the client devices are deuathenticated if users fail to enter their credentials after 35 seconds; that is (3*10 + 5) = 35 seconds.

Authentication for Sleeping Clients

Authenticating sleeping clients

A sleeping client is a wireless device that

  • has completed web authentication and been granted guest access

  • is allowed to enter sleep mode and wake up without reauthenticating through the login page, and

  • the controller stores sleeping client information for a configurable duration before requiring reauthentication.

The valid range is 10 minutes to 43200 minutes, with the default being 720 minutes. You can also configure this duration on WebAuth parameter map that is mapped to a WLAN. The sleeping client timer is activated when conditions such as idle timeout, session timeout, WLAN disabling, or AP nonoperational status occur.


Caution

If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

Feature History

Feature Name

Release

Description

Webauth Sleeping Client Support

Cisco IOS XE 17.1.1s

The web authentication sleeping clients feature supports multiple combinations of authenticationsfor a given client, which are configured on the WLAN profile.

Scenarios where sleeping clients do not need reauthentication

  • Suppose there are two controller s in a mobility group. A client that is associated with one controller goes to sleep and then wakes up and gets associated with the other controller .

  • Suppose there are three controller s in a mobility group. A client that is associated with the second controller that is anchored to the first controller goes to sleep, wakes up, and gets associated with the third controller .

  • A client sleeps, wakes up and gets associated with the same or different export foreign controller that is anchored to the export anchor.

Restrictions on authenticating sleeping clients

  • If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

  • The sleep client feature works only for WLAN configured with WebAuth security.

  • You can configure the sleeping clients only on a per WebAuth parameter-map basis.

  • The authentication of sleeping clients feature is supported only on WLANs that have Layer 3 security enabled.

  • When Layer 3 security is enabled, the Authentication, Passthrough, and On MAC Filter failure web policies are supported. The Splash Page Web Redirect web policy is not supported.

  • The central web authentication of sleeping clients is not supported.

  • The authentication of sleeping clients feature is not supported on guest LANs and remote LANs.

  • A guest access sleeping client that has a local user policy is not supported. In this case, the WLAN-specific timer is applied.

Configure authentication for sleeping clients (GUI)

Enable authentication for sleeping clients to ensure devices can maintain secure network access even after entering sleep mode.

Sleeping clients, such as laptops or mobile devices, periodically enter low-power states. You configure authentication to ensure they reconnect securely and seamlessly when they wake.

Procedure

Step 1

Choose Configuration > Security > Web Auth.

Step 2

In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.

Step 3

Check Sleeping Client Status check box.

Step 4

Click Update & Apply to Device.

Authentication for sleeping clients is now enabled. Devices entering sleep mode will reconnect securely without manual intervention.

Configure authentication for sleeping clients (CLI)

Configure authentication parameters to manage sleeping wireless clients and control their session persistence on the device.

Sleeping clients are wireless devices that temporarily disconnect due to power-saving or roaming behaviors. Configuring authentication for sleeping clients ensures they are recognized and handled appropriately during these periods.

Procedure

Step 1

Create a parameter map and enters parameter-map webauth configuration mode.

Example:

Device(config)# parameter-map type webauth global

Step 2

Configure the sleeping client timeout to 100 minutes.

Example:

Device(config-params-parameter-map)# sleeping-client timeout 100

Valid range is between 10 minutes and 43200 minutes.

Note

 

If you do not use the timeout keyword, the sleeping client is configured with the default timeout value of 720 minutes.

Step 3

Exit parameter-map webauth configuration mode and returns to privileged EXEC mode.

Example:

Device# end

Step 4

(Optional) Show the MAC address of the clients and the time remaining in their respective sessions.

Example:

Device# show wireless client sleeping-client

Step 5

(Optional) Delete sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client —Deletes all sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client mac-address mac-addr —Deletes the specific MAC entry from the sleeping client cache.

Example:

Device# clear wireless client sleeping-client 
mac-address 00e1.e1e1.0001

The device displays the global configuration prompt, allowing you to make configuration changes.