Scenario 5 - HTTP Listener
analyses of Scenarios 1 through 4 focus on illustrating the
authorization processes that can extend the basic Cut-Through Proxy
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.
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
The redirect keyword instructs the ASA to direct HTTP and HTTPS requests to an authentication web page served by the firewall itself.
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)
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.
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).