When a user initiates an HTTP session through the firewall, the authentication proxy is triggered. The authentication proxy first checks to see if the user has been authenticated. If a valid authentication entry exists for the user, the connection is completed with no further intervention by the authentication proxy. If no entry exists, the authentication proxy responds to the HTTP connection request by prompting the user for a username and password.

The figure below illustrates the authentication proxy HTML login page.

Figure 1

Authentication Proxy Login Page

Users must successfully authenticate themselves with the authentication server by entering a valid username and password.

If the authentication succeeds, the user’s authorization profile is retrieved from the AAA server. The authentication proxy uses the information in this profile to create dynamic access control entries (ACEs) and add them to the inbound (input) access control list (ACL) of an input interface and to the outbound (output) ACL of an output interface, if an output ACL exists at the interface. This process enables the firewall to allow authenticated users access to the network as permitted by the authorization profile. For example, a user can initiate a Telnet connection through the firewall if Telnet is permitted in the user’s profile.

If the authentication fails, the authentication proxy reports the failure to the user and prompts the user with multiple retries. If the user fails to authenticate after five attempts, the user must wait two minutes and initiate another HTTP session to trigger authentication proxy.

The login page is refreshed each time the user makes requests to access information from a web server.

The authentication proxy customizes each of the access list entries in the user profile by replacing the source IP addresses in the downloaded access list with the source IP address of the authenticated host.

At the same time that dynamic ACEs are added to the interface configuration, the authentication proxy sends a message to the user confirming that the login was successful. The figure below illustrates the login status in the HTML page.

Figure 2

Authentication Proxy Login Status Message

The authentication proxy sets up an inactivity (idle) timer for each user profile. As long as there is activity through the firewall, new traffic initiated from the user’s host does not trigger the authentication proxy, and authorized user traffic is permitted access through the firewall.

If the idle timer expires, the authentication proxy removes the user’s profile information and dynamic access lists entries. When this happens, traffic from the client host is blocked. The user must initiate another HTTP connection to trigger the authentication proxy.

The authentication proxy uses JavaScript to help achieve secure authentication using the client browser. Secure authentication prevents a client from mistakenly submitting a username and password to a network web server other than the authentication proxy router.

• Operation with JavaScript
  
• Operation Without JavaScript
  

Unlike some Cisco IOS Firewall features that operate transparently to the user, the authentication proxy feature requires some user interaction on the client host. The table below describes the interaction of the authentication proxy with the client host.

Here are examples of situations in which you might use the authentication proxy:

• You want to manage access privileges on an individual (per-user) basis using the services provided by the authentication servers instead of configuring access control based on host IP address or global access policies. Authenticating and authorizing users from any host IP address also allows network administrators to configure host IP addresses using DHCP.
• You want to authenticate and authorize local users before permitting access to intranet or Internet services or hosts through the firewall.
• You want to authenticate and authorize remote users before permitting access to local services or hosts through the firewall.
• You want to control access for specific extranet users. For example, you might want to authenticate and authorize the financial officer of a corporate partner with one set of access privileges while authorizing the technology officer for that same partner to use another set of access privileges.
• You want to use the authentication proxy in conjunction with VPN client software to validate users and to assign specific access privileges.
• You want to use the authentication proxy in conjunction with AAA accounting to generate “start” and “stop” accounting records that can be used for billing, security, or resource allocation purposes, thereby allowing users to track traffic from the authenticated hosts.

Apply the authentication proxy in the inbound direction at any interface on the router where you want per-user authentication and authorization. Applying the authentication proxy inbound at an interface causes it to intercept a user’s initial connection request before that request is subjected to any other processing by the firewall. If the user fails to gain authentication with the AAA server, the connection request is dropped.

How you apply the authentication proxy depends on your security policy. For example, you can block all traffic through an interface and enable the authentication proxy feature to require authentication and authorization for all user initiated HTTP connections. Users are authorized for services only after successful authentication with the AAA server.

The authentication proxy feature also allows you to use standard access lists to specify a host or group of hosts whose initial HTTP traffic triggers the proxy.

The figure below shows the authentication proxy applied at the LAN interface with all network users required to be authenticated upon the initial connection (all traffic is blocked at each interface).

Figure 4

Applying the Authentication Proxy at the Local Interface

The figure below shows the authentication proxy applied at the dial-in interface with all network traffic blocked at each interface.

Figure 5

Applying the Authentication Proxy at an Outside Interface

Given a one-time password, the user enters the username and one-time password in the HTML login page as usual.

The user must enter the correct token password within the first three attempts. After three incorrect entries, the user must enter two valid token passwords in succession before authentication is granted by the AAA server.

The authentication proxy is compatible with Cisco IOS software and with Cisco IOS security features:

• Cisco IOS Firewall Intrusion Detection System (IDS)
• NAT
• CBAC
• IPSec encryption
• VPN client software

The authentication proxy works transparently with the Cisco IOS Firewall IDS and IPSec encryption features.

• NAT Compatibility
  
• CBAC Compatibility
  
• VPN Client Compatibility
  

Using the authentication proxy, you can generate “start” and “stop” accounting records with enough information to be used for billing and security auditing purposes. Thus, you can monitor the actions of authenticated hosts that use the authentication proxy service.

When an authentication proxy cache and associated dynamic access control lists are created, the authentication proxy will start to track the traffic from the authenticated host. Accounting saves data about this event in a data structure stored with the data of other users. If the accounting start option is enabled, you can generate an accounting record (a “start” record) at this time. Subsequent traffic from the authenticated host will be recorded when the dynamic ACL created by the authentication proxy receives the packets.

When an authentication proxy cache expires and is deleted, additional data, such as elapsed time, is added to the accounting information and a “stop” record is sent to the server. At this point, the information is deleted from the data structure.

The accounting records for the authentication proxy user session are related to the cache and the dynamic ACL usage.

Note	The accounting records must include RADIUS attributes 42, 46, and 47 for both RADIUS and TACACS+.

For more information on RADIUS attributes, refer to the appendix “RADIUS Attributes.”

The authentication proxy monitors the level of incoming HTTP requests. For each request, the authentication proxy prompts the user’s for login credentials. A high number of open requests could indicate that the router is the subject of a denial-of-service (DoS) attack. The authentication proxy limits the level of open requests and drops additional requests until the number of open requests has fallen below 40.

If the firewall is experiencing a high level of connection requests requiring authentication, legitimate network users may experience delays when making connections, or the connection may be rejected and the user must try the connection again.

When the authentication proxy is triggered, it creates a dynamic opening in the firewall by temporarily reconfiguring an interface with user access privileges. While this opening exists, another host might spoof the authenticated users address to gain access behind the firewall. The authentication proxy does not cause the address spoofing problem; the problem is only identified here as a matter of concern to the user. Spoofing is a problem inherent to all access lists, and the authentication proxy does not specifically address this problem.

Lock-and-key is another Cisco IOS Firewall feature that uses authentication and dynamic access list to provide user access through the firewall. The table below compares the authentication proxy and lock-and-key features.

Use the authentication proxy in any network environment that provides a per-user security policy. Use lock-and-key in network environments that might benefit from local authentication and a limited number of router-based access control policies based on host addresses. Use lock-and-key in environments not using the Cisco Secure Integrated Software.

1.    router(config)# aaa new-model

2.    router(config)# aaa authentication login default TACACS+ RADIUS

3.    router(config)# aaa authorization auth-proxy default [method1 [method2...]]

4.    router(config)# aaa accounting auth-proxy default start-stop group tacacs+

5.    router(config)# tacacs-server host hostname

6.    router(config)# tacacs-server key key

7.    router(config)# access-list access-list-number

In addition to configuring AAA on the firewall router, the authentication proxy requires a per-user access profile configuration on the AAA server. To support the authentication proxy, configure the AAA authorization service auth-proxy on the AAA server as outlined here:

• Define a separate section of authorization for the auth-proxy keyword to specify the downloadable user profiles. This keyword does not interfere with other type of services, such as EXEC. The following example shows a user profile on a TACACS server:

default authorization = permit
key = cisco
user = newuser1 {
login = cleartext cisco
service = auth-proxy
{
priv-lvl=15
proxyacl#1="permit tcp any any eq 26"
proxyacl#2="permit icmp any host 60.0.0.2”
proxyacl#3="permit tcp any any eq ftp"
proxyacl#4="permit tcp any any eq ftp-data"
proxyacl#5="permit tcp any any eq smtp"
proxyacl#6="permit tcp any any eq telnet"
}
}

• The only supported attribute in the AAA server user configuration is proxyacl#n.Use the proxyacl#n attribute when configuring the access lists in the profile. The attribute proxyacl#n is for both RADIUS and TACACS+ attribute-value (AV) pairs.
• The privilege level must be set to 15 for all users.
• The access lists in the user profile on the AAA server must have access commands that contain only the permitkeyword.
• Set the source address to the anykeyword in each of the user profile access list entries. The source address in the access lists is replaced with the source address of the host making the authentication proxy request when the user profile is downloaded to the firewall.
• The supported AAA servers are:
  • CiscoSecure ACS 2.1.x for Windows NT
  • CiscoSecure ACS 2.3 for Windows NT
  • CiscoSecure ACS 2.2.4 for UNIX
  • CiscoSecure ACS 2.3 for UNIX
  • TACACS+ server (vF4.02.alpha)
  • Ascend RADIUS server radius-980618 (required attribute-value pair patch)
  • Livingston RADIUS server (v1.16)

Refer to the section AAA Server User Profile Example for sample AAA server configurations.

1.    enable

2.    configure terminal

3.    ip http server

4.    ip http access-class access-list-number

1.    enable

2.    configure terminal

3.    ip auth-proxy auth-cache-time min

4.    ip auth-proxy auth-proxy-banner

5.    ip auth-proxy name auth-proxy-name http [auth-cache-time min] [list {acl acl-name} ]

6.    interface type

7.    ip auth-proxy auth-proxy-name

• Checking the Authentication Proxy Configuration
  
• Displaying the User Authentication Entries
  
• Establishing User Connections with JavaScript
  
• Establishing User Connections Without JavaScript
  

You can display dynamic access list entries when they are in use. After an authentication proxy entry is cleared by you or by the idle timeout parameter, you can no longer display it. The number of matches displayed indicates the number of times the access list entry was hit.

To view dynamic access lists and any temporary access list entries that are currently established by the authentication proxy, use the show ip access-lists command in privileged EXEC mode:

router# show ip access-lists

Consider the following example where ACL 105 is applied inbound at the input interface where you configure authentication proxy. The initial display shows the contents of the ACLs prior to authentication. The second display shows the same displays after user authentication with the AAA server.

Note

If NAT is configured, the show ip access list command might display the translated host IP address for the dynamic ACL entry or the IP address of the host initiating the connection. If the ACL is applied on the NAT outside interface, the translated address is displayed. If the ACL is applied on the NAT inside interface, the IP address of the host initiating the connection is displayed. The show ip auth-proxy cache command always displays the IP address of the host initiating the connection.

For example, the following is a list of ACL entries prior to the authentication proxy:

Router# show ip access-lists
    .
    .
    .
Extended IP access list 105
 deny tcp any any eq telnet
 deny udp any any
 permit tcp any any (28 matches)
 permit ip any any

The following sample output shows a list of ACL entries following user authentication:

Router# show ip access-lists
    .
    .
    .
Extended IP access list 105
! The ACL entries following user authentication are shown below.
 permit tcp host 192.168.25.215 any eq 26
 permit icmp host 192.168.25.215 host 60.0.0.2
 permit tcp host 192.168.25.215 any eq telnet
 permit tcp host 192.168.25.215 any eq ftp
 permit tcp host 192.168.25.215 any eq ftp-data
 permit tcp host 192.168.25.215 any eq smtp
 deny tcp any any eq telnet
 deny udp any any
 permit tcp any any (76 matches)
 permit ip any any

When the authentication proxy is in use, dynamic access lists dynamically grow and shrink as authentication entries are added and deleted. To display the list of authentication entries, use the show ip auth-proxy cachecommand. To manually delete an authentication entry, use the clear ip auth-proxy cachecommand in privileged EXEC mode:

router# clear ip auth-proxy cache 

{*
 | host ip address} 

• AAA Configuration Example
  
• HTTP Server Configuration Example
  
• Authentication Proxy Configuration Example
  
• Interface Configuration Example
  

• Router 1 Configuration Example
  
• Router 2 Configuration Example
  

• Router 1 Configuration Example
  
• Router 2 Configuration Example
  

• CiscoSecure ACS 2.3 for Windows NT
  
• CiscoSecure ACS 2.3 for UNIX
  
• TACACS+ Server
  
• Livingston Radius Server
  
• Ascend Radius Server