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

다운로드
페이지 619
 
8-25
Cisco IronPort AsyncOS 7.7.5 for Web User Guide
 
Chapter 8      Identities
Example Identity Policies Tables
against the authentication server(s) defined in RealmA. If the user exists in RealmA, the Web Proxy 
assigns the third Identity group to the transaction. If the user does not exist in RealmA, the Web 
Proxy terminates the client request because the client failed authentication.
Note that in this scenario, most client requests will never match the global Identity group because of the 
user defined Identity group (the third group) that applies to all subnets, has no advanced options, and 
requires authentication. Any client on the network that does not match the first or second Identity group 
will match the third Identity group. The exception to this is for HTTPS requests when the appliance is 
in transparent mode with cookie-based authentication. Any client on a subnet other than 10.1.1.1 will 
match the global Identity group even though it requires authentication.
Example 2
 shows a policies table with two user defined Identity groups. The first Identity group applies 
to all subnets, requires authentication, and specifies RealmA for authentication. The second Identity 
group applies to all subnets, requires authentication, and specifies RealmB for authentication. Neither 
Identity group has any advanced option configured. The global Identity group applies to all subnets, 
requires authentication, and specifies the All Realms sequence for authentication.
In this scenario, when a client sends a request for a URL, the Web Proxy evaluates the first Identity group 
and determines that the Identity group applies to all subnets and has no advanced options configured. It 
determines that the Identity group requires authentication and that the only realm specified in the 
Identity group is RealmA. Therefore, in order for a client on any subnet to pass authentication, it must 
exist in RealmA
.
When a client that exists in RealmA sends a request for a URL, the client passes authentication and the 
Web Proxy assigns the first Identity group to the transaction. When a client that does not exist in RealmA 
sends a request for a URL, the client fails authentication and the Web Proxy terminates the request.
Note that when a client in RealmB sends a request for a URL, the Web Proxy does not match the client 
request with the second Identity group. This is because a previous Identity group already applies to the 
same subnets (and the exact same advanced options, which in this example is none) in the second Identity 
group and it requires authentication, but from RealmA instead. Clients in RealmB do not “fall through” 
to the second Identity group.
If you want users in RealmB to have different Access, Decryption, and Routing Policy settings applied 
to them than users in RealmA, perform the following steps:
Step 1
Create an authentication sequence that contains both RealmA and RealmB. You can choose the order of 
the realms in the sequence depending on your business needs.
Step 2
Create one Identity group and configure it for whichever subnets on which users in RealmA and RealmB 
might exist. In this example, you would configure the Identity group for all subnets. 
Step 3
Configure the Identity group to use the sequence you defined in step 
Table 8-5
Policies Table Example 2 
Order
Subnet(s)
Authentication 
Required?
Realm or 
Sequence
Advanced Options
1
All
Yes
RealmA
none
2
All
Yes
RealmB
none
Global Identity 
policy
All
Yes
All Realms
N/A (none by default)