Cisco Cisco Web Security Appliance S170 사용자 가이드
9-4
Cisco IronPort AsyncOS 7.5.7 for Web User Guide
Chapter 9 Identities
Evaluating Identity Group Membership
•
Cookie-based authentication. When the appliance is configured to use cookie-based authentication
surrogates, it does not get cookie information from clients for HTTPS and FTP over HTTP requests.
Therefore, it cannot get the user name from the cookie. How HTTPS and FTP over HTTP requests
are matched against the Identity groups varies based on other factors. For more information, see
surrogates, it does not get cookie information from clients for HTTPS and FTP over HTTP requests.
Therefore, it cannot get the user name from the cookie. How HTTPS and FTP over HTTP requests
are matched against the Identity groups varies based on other factors. For more information, see
•
Identity uniqueness. Verify the Identity group membership requirements are unique for each
Identity group. If two Identity groups require the exact same membership, then client requests never
match the lower Identity group. If any non-Identity policy uses the lower Identity group, client
requests never match that policy.
Identity group. If two Identity groups require the exact same membership, then client requests never
match the lower Identity group. If any non-Identity policy uses the lower Identity group, client
requests never match that policy.
•
Global Identity policy. The global Identity policy does not require authentication by default when
you create an authentication realm. If you want the global Identity policy to require authentication,
you must assign an authentication realm, authentication sequence, or the All Realms sequence to the
global Identity policy.
you create an authentication realm. If you want the global Identity policy to require authentication,
you must assign an authentication realm, authentication sequence, or the All Realms sequence to the
global Identity policy.
For some examples of how the Web Proxy matches client requests to an Identity group for different
Identity policies tables, see
Identity policies tables, see
.
Understanding How Authentication Affects HTTPS and FTP over HTTP Requests
How the Web Proxy matches HTTPS and FTP over HTTP requests with Identities depends on the type
of request (either explicitly forwarded or transparently redirected to the Web Proxy) and the
authentication surrogate type:
of request (either explicitly forwarded or transparently redirected to the Web Proxy) and the
authentication surrogate type:
•
No authentication surrogates. The Web Proxy matches HTTPS and FTP over HTTP requests with
Identity groups the same way it matches HTTP requests. For a diagram of how this occurs, see
Identity groups the same way it matches HTTP requests. For a diagram of how this occurs, see
.
•
IP-based authentication surrogates and explicit requests. The Web Proxy matches HTTPS and
FTP over HTTP requests with Identity groups the same way it matches HTTP requests. For a
diagram of how this occurs, see
FTP over HTTP requests with Identity groups the same way it matches HTTP requests. For a
diagram of how this occurs, see
•
IP-based authentication surrogates and transparent requests. The Web Proxy matches FTP over
HTTP requests with Identity groups the same way it matches HTTP requests. But for HTTPS
requests, the behavior is different, depending on whether or not the HTTPS request comes from a
client that has authentication information available from an earlier HTTP request:
HTTP requests with Identity groups the same way it matches HTTP requests. But for HTTPS
requests, the behavior is different, depending on whether or not the HTTPS request comes from a
client that has authentication information available from an earlier HTTP request:
–
Information available from a previous HTTP request. The Web Proxy matches HTTPS
requests with Identity groups the same way it matches HTTP requests. HTTPS requests are
treated with the Identity associated with the IP address.
requests with Identity groups the same way it matches HTTP requests. HTTPS requests are
treated with the Identity associated with the IP address.
–
No information available from a previous HTTP request. When the Web Proxy has no
credential information for the client, then it either fails the HTTPS request or decrypts the
HTTPS request in order to authenticate the user, depending on how you configure the HTTPS
Proxy. Use the HTTPS Transparent Request setting on the Security Services > HTTPS Proxy
page to define this behavior.
credential information for the client, then it either fails the HTTPS request or decrypts the
HTTPS request in order to authenticate the user, depending on how you configure the HTTPS
Proxy. Use the HTTPS Transparent Request setting on the Security Services > HTTPS Proxy
page to define this behavior.
For a diagram of how this occurs, see
•
Cookie-based authentication surrogates and transparent requests. When the appliance uses
cookie-based authentication, the Web Proxy does not get cookie information from clients for HTTPS
and FTP over HTTP requests. Therefore, it cannot get the user name from the cookie. In this
situation, HTTPS and FTP over HTTP requests still match the Identity group according to the other
membership criteria, but the Web Proxy does not prompt clients for authentication even if the
Identity group requires authentication. Instead, the Web Proxy sets the user name to NULL and
considers the user as unauthenticated. Then, when the unauthenticated request is evaluated against
cookie-based authentication, the Web Proxy does not get cookie information from clients for HTTPS
and FTP over HTTP requests. Therefore, it cannot get the user name from the cookie. In this
situation, HTTPS and FTP over HTTP requests still match the Identity group according to the other
membership criteria, but the Web Proxy does not prompt clients for authentication even if the
Identity group requires authentication. Instead, the Web Proxy sets the user name to NULL and
considers the user as unauthenticated. Then, when the unauthenticated request is evaluated against