Cisco Cisco Expressway Maintenance Manual

When the Expressway uses a policy service it sends information about the call request to the service in a POST 
message using a set of name-value pair parameters. Those parameters include information about whether the 
request has come from an authenticated source or not.

More information about policy services, including example CPL, can be found in External Policy on Expressway 
Deployment Guide.

If you are using the Call Policy rules generator on the Expressway, source matches are carried out against 
authenticated sources. To specify a match against an unauthenticated source, just use a blank field.  (If a source is 
not authenticated, its value cannot be trusted).

If you use uploaded, handcrafted local CPL to manage your Call Policy, you are recommended to make your CPL 
explicit as to whether it is looking at the authenticated or unauthenticated origin.

 

■

If CPL is required to look at the unauthenticated origin (for example, when checking non-authenticated 
callers) the CPL must use 

. (However, if the user is unauthenticated, they can call 

themselves whatever they like; this field does not verify the caller.)

 

■

To check the authenticated origin (only available for authenticated or “treat as authenticated” devices) the 
CPL should use 

.

Note that due to the complexity of writing CPL scripts, you are recommended to use an external policy service 
instead.

Authentication Policy Configuration Options

Authentication policy behavior varies for H.323 and  SIP messages.

The primary authentication policy configuration options and their associated behavior are as follows:

 

■

Check credentials: verify the credentials using the relevant authentication method. Note that in some 
scenarios, messages are not challenged, see below.

 

■

Do not check credentials: do not verify the credentials and allow the message to be processed.

 

■

Treat as authenticated: do not verify the credentials and allow the message to be processed as if it is has 
been authenticated. This option can be used to cater for endpoints from third-party suppliers that do not 
support authentication within their registration mechanism. Note that in some scenarios, messages are 
allowed but will still be treated as though they are unauthenticated, see below.

Authentication policy is selectively configurable for different zone types, based on whether they receive messaging:

 

■

The Default Zone, Neighbor zones, traversal client zones, traversal server zones and Unified Communications 
traversal zones all allow configuration of authentication policy

 

■

DNS and ENUM zones do not receive messaging and so have no authentication policy configuration.

To edit a zone's Authentication policy, go to Configuration > Zones > Zones and click the name of the zone. The 
policy is set to Do not check credentials by default when you create a new zone.

The behavior varies for H.323 and SIP messages as shown in the tables below:

Policy

Behavior

Check 
credentials

Messages are classified as either authenticated or unauthenticated depending on whether any 
credentials in the message can be verified against the authentication database.

If no credentials are supplied, the message is always classified as unauthenticated.

Do not check 
credentials

Message credentials are not checked and all messages are classified as unauthenticated.

89

Cisco Expressway Administrator Guide