Identity on Cisco Firewalls : ASA User-Level Control with Cut-Through Proxy (part 6) - HTTP Listener

Scenario 5 - HTTP Listener

The analyses of Scenarios 1 through 4 focus on illustrating the authorization processes that can extend the basic Cut-Through Proxy authentication functionality.

Knowing now what happens behind the scenes in those scenarios, it is time to shift gears to the study of the HTTP Listener technique, a feature designed to enhance the authentication experience of a user subject to Cut-Through Proxy interception.

The HTTP Listener mechanism, working with the aaa authentication match command, redirects all the web requests intended to traverse the firewall to an authentication web page served by the ASA.

Example 15 documents the additional commands necessary to enable the HTTP Listener on a given interface already configured for Cut-Through Proxy. This example assumes that the commands documented in Examples 1 and 3 are already in place.

Example 15. Enabling HTTP Listener on an Interface

! Enabling the HTTP Listener mechanism on interface "dmz" ! aaa authentication listener http dmz port www redirect ! ! Enabling the HTTPS listener mechanism on interface "dmz" ! aaa authentication listener https dmz port https redirect

Note

The redirect keyword instructs the ASA to direct HTTP and HTTPS requests to an authentication web page served by the firewall itself.

Note

The tool shown in the browser’s windows at the bottom of Figures 4 and 5 is the HTTP Watch Basic Edition, an HTTP viewer that provides visibility of the HTTP methods invoked, the operations happening within a session, and the corresponding status codes. This information may be useful for revealing, for instance, the redirect messages employed by the HTTP Listener process.

Figure 4 shows the browser screen presented to the user after it attempts to open an HTTP connection to 172.16.200.200. The IP address included in the URL shown in this figure has changed to 172.16.201.1, which corresponds to the “dmz” interface of the ASA (refer to Figure 2 for addressing details).

Figure 4. HTTP Listener - User Perspective (1)

Figure 5 displays the browser screen presented to the users after they click on the Log In Now button presented on Figure 4. This new process helps characterize that the original connection attempt has been intercepted and that user credentials are required before traffic can be allowed through the ASA.

Figure 5. HTTP listener - User Perspective (2)

Note

If the command aaa authentication secure-http-client is added to the configuration analyzed in Example 5, it instructs the ASA to always receive the user credentials via HTTPS, even if the original connection used HTTP.

Figure 6 is an attempt to consolidate the sequence of operations that a packet can undergo when it arrives at an ASA interface configured for Cut-Through Proxy. The conception of the flowchart assumes that authorization is performed with the contribution of some of the RADIUS attributes that have been discussed so far.

Figure 6. Cut-Through Proxy Flowchart Using RADIUS Attributes for Authorization

It is indispensable to keep in mind that this flowchart covers the order of operations that are part of the ASA algorithm, in the inbound direction, before any eventual NAT process comes into play. The focus here is to visualize some processes that have precedence over the Cut-Through Proxy feature (existence of the flow, availability of routing information, and explicit permission for the triggering protocol in the interface ACL).