Cisco Cisco Web Security Appliance S170 사용자 가이드

다운로드
페이지 734
 
9-24
Cisco IronPort AsyncOS 7.5.7 for Web User Guide
Chapter 9      Identities
Example Identity Policies Tables
Step 7
If you add another Identity group, repeat steps 
 through 
.
Step 8
Submit and commit your changes.
Example Identity Policies Tables
This section shows some sample Identity groups defined in an Identity policies table and describes how 
the Web Proxy evaluates different client requests using each Identity policies table.
Example 1
 shows an Identity policies table with three user defined Identity groups. The first Identity 
group applies to a particular subnet and does not require authentication. The second Identity group 
applies to all subnets and requests for URLs in the “Proxies & Translators” category, and requires 
authentication on RealmA. The third Identity group applies to all subnets, has no advanced options 
defined, and requires authentication on RealmA. The global Identity policy applies to all subnets (by 
definition) and does not require authentication. 
The Web Proxy matches client requests to Identity groups in this scenario differently, depending on the 
client’s subnet and the URL category of the request:
  •
Any client on subnet 10.1.1.1 for any URL. When a client on subnet 10.1.1.1 sends a request for 
any URL, the Web Proxy evaluates the first Identity group and determines that the client subnet 
matches the first Identity group subnet. Then it determines that no authentication is required and no 
advanced options are configured, so it assigns the first Identity group to the transaction.
  •
Any client on a subnet other than 10.1.1.1 for URLs in the “Proxies & Translators” URL 
category.
 When a client on a subnet other than 10.1.1.1 sends a request for a URL in the “Proxies 
& Translators” category, the Web Proxy evaluates the first Identity group and determines that the 
client subnet is not listed in the first Identity group’s list of subnets. Therefore, it evaluates the 
second Identity group, and then determines that the client subnet is listed in the second Identity 
group’s list of subnets. Then it determines that the URL in the request matches the URL category in 
the second Identity group’s advanced section. Then it determines that the second Identity group 
requires authentication, so it tries to authenticate the user against the authentication server(s) 
defined in RealmA. If the user exists in RealmA, the Web Proxy assigns the second Identity group 
to the transaction. If the user does not exist in RealmA, AsyncOS terminates the client request 
because the client failed authentication.
Table 9-3
Policies Table Example 1 
Order
Subnet(s)
Authentication 
Required?
Realm or 
Sequence
Advanced Options
1
10.1.1.1
No
N/A
none
2
All
Yes
RealmA
URL Category is “Proxies & 
Translators”
3
All
Yes
RealmA
none
Global Identity 
policy
All
(by default)
No
N/A
N/A (none by default)