Cisco Internet Streamer CDS 2.5 Software Configuration Guide
Creating Service Rule Files
Downloads: This chapterpdf (PDF - 192.0KB) The complete bookPDF (PDF - 4.65MB) | Feedback

Creating Service Rule Files

Table Of Contents

Creating Service Rule Files

Introduction

Converting Old Service Rules to New Service Rules

Adding a Service Rule File to the CDS

Service Rule File Structure and Syntax

Service Rule XML Schema

Service Rule File Example

Service Rule File for URL Validation and the Exclude-Validation Attribute

Exclude Client IP Address from URL Validation

Exclude Expiry Time from URL Validation

Exclude Both the Client IP Address and the Expiry Time from URL Validation


Creating Service Rule Files


This appendix describes the Service Rule file used by a delivery service to specify the service rules for all the SEs in a delivery service. This appendix consists of the following topics:

Introduction

Service Rule XML Schema

Service Rule File Example


Note The Service Rule file is only supported in Release 2.5.7 and later releases and only for the Web Engine. All other protocol engines should continue to configure service rules by device. For more information, see the "Configuring Service Rules" section. For the Web Engine, the Service Rule file must be used if service rules are to be configured.

The Authorization Service must be enabled on all SEs participating in a delivery service that uses the Service Rule Configuration. The Authorization Service is enabled by default. For more information, see the "Configuring the Authorization Service" section.


When the Authorization Service and Service Rules are configured by way of XML configuration files that are associated with a delivery service, each client request goes through the following processing order:

1. SE bypass (this is used for multi-tiered SEs), no configuration is required

2. Service Rules

3. Authorization Service Network element

4. Authorization Service Geo element

For information about the Authorization Service, see "Creating Authorization Service Files."

Introduction

The Service Rule file is an XML file used to specify the service rules for all the SEs in a delivery service. Just the same as configuring service rules for each SE, the Service Rule file allows you to specify a set of rules, each clearly identified by an action and a pattern, for all the SEs in a delivery service. Subsequently, for every incoming request, if a pattern for a rule matches the given request, the corresponding action for that rule is taken. You do not need to enable Service Rules on each SE for the Web Engine, just create a Service Rule file, upload it to the CDS, and select it through for the delivery service.

Converting Old Service Rules to New Service Rules

The following example shows the commands for configuring a service rule that performs a URL rewrite using the old mechanism:

SE (config)# rule enable
SE (config)# rule action rewrite pattern-list 1
SE (config)# rule pattern-list 1 url-regsub http://(.*).rfqdn2.cds.cisco.com/(.*) 
http://$2
 
   

The Service Rule XML file for the above rule is as follows:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
     <Revision>1.0</Revision>
     <CustomerName>MOD</CustomerName>
     <Rule_Patterns>
          <PatternListGrp id = "grp1">
               <UrlRegex>(.*).rfqdn2.cds.cisco.com/(.*)</UrlRegex>
          </PatternListGrp>
     </Rule_Patterns>
     <Rule_Actions>     
        <Rule_Allow matchGroup = "grp1" protocol = "http" />
        <Rule_UrlRewrite matchGroup = "grp1" protocol = "http" regsub = 
"http://(.*).rfqdn2.cds.cisco.com/(.*)" rewrite-url = "http://$2" />
     </Rule_Actions>
</CDSRules>
 
   

The pattern type header-field is not supported in the new XML Service Rule file. The following service rule actions are not supported in the new XML Service Rule file, except were noted (no-cache is supported in Release 2.5.9):

generate-url-signature

redirect

refresh

replace

no-cache (supported in Release 2.5.9)

Table F-1 shows the mapping between a service rule pattern command and an XML pattern.

Table F-1 Mapping Service Rule Patterns—CLI Format to XML Format 

Pattern Type
CLI Pattern
XML Pattern

Domain

rule pattern-list 1 domain rfqdn.cds.com

<PatternListGrp id = "1">
<Domain>rfqdn.cds.com</Domain>
</PatternListGrp>

SrcIp

rule pattern-list 1 src-ip 1.1.1.1 255.255.255.0

<PatternListGrp id = "1">
<SrcIp>1.1.The 1.1</SrcIp>
</PatternListGrp>

UrlRegex

rule pattern-list 2 url-regex http:\/\/.*.svc01.cdn.t-online.de\/web[0-9]+\/streaming\/CDN_testprovider_2\/streaming\/.*

<PatternListGrp id = "2">
<UrlRegex>
http:\/\/.*.svc01.cdn.t- online.de\/web[0- 9]+\/streaming\/CDN_testprovider_2\/streaming\/.*
</UrlRegex>
</PatternListGrp>


Table F-3 shows the mapping between a service rule action command and an XML action.

Table F-2 Mapping Service Rule Actions—CLI Format to XML Format

Action Type
CLI Action
XML Action

Allow

rule action allow pattern-list 1 protocol http

<Rule_Allow matchGroup = "1" protocol = "http" />

Block

rule action block pattern-list 2 protocol http

<Rule_Block matchGroup = "2" protocol = "http" />

Validate

rule action validate-url-signature error-redirect-url "http://wwwin.cisco.com" pattern-list 1 protocol http

<Rule_Validate matchGroup = "1" protocol = "http" error-redirect-url = "http://wwwin.cisco.com" exclude-validation = "all" />

UrlRewrite

rule pattern-list 3 url-regsub http://(.*.)cdsis.com/(.*.)mp4(.*.)
http://customer.com/%29%28(.*.)
http://$1$2$3mp4 rule action rewrite pattern-list 3 protocol http

<Rule_UrlRewrite matchGroup = "1"
protocol = "http"
regsub = "http://(.*.)cdsis.com/(.*.)mp4(.*.)
http://customer.com/%29%28(.*.)"
rewrite-url = " http://$1$2$3mp4" />



Note The Rule_NoCache action type is only supported in Release 2.5.9.


Adding a Service Rule File to the CDS

The Service Rule files can be created using any ASCII text-editing tool. The Service Rule file can be uploaded using the Service Rule File Registration page. For more information see the "Service Rule File Registration" section. When the file has been uploaded, you select it through the delivery service Service Rule Configuration page. For more information, see the "Service Rule File Config" section.

Service Rule File Structure and Syntax

Table F-3 defines the Service Rule file elements.

Table F-3 Service Rule File Elements 

Element
Subelements
Attributes
Description

CDSRule

Revision

 

Optional. Revision number to specify the version of this file.

CustomerName

 

Optional. Customer name associated with this file.

Rule_Patterns

 

Patterns to match for a specified action. There can be only one Rule_Patterns element for a Service Rule file.

Rule_Actions

 

Action to take when a pattern is matched. There can be only one Rule_Actions element for a Service Rule file.

Rule_Patterns

PatternListGrp

 

Marks the beginning and ending of all the defined patterns in this file.

PatternListGrp

Domain
Header
SrcIp
UrlRegex

id

The PatternListGrp id attribute is used to identify the pattern list group and can be up to 128 alphanumeric characters.

Note The Header element is not supported in Release 2.5.7 and later releases.

Domain

   

The Domain element is used to match the domain name in the URL or the host header against a regular expression. For more information, see the Table 4-12.

Note When VOD (prefetch/caching) and live streaming share the same content origin, and the Service Rules XML file is configured to validate the signed URL where the domain must match the Service Routing Domain Name, make sure to create rule patterns for the URL validation to match both the Service Routing Domain Name and the Origin Server FQDN. Additionally, when the URL is signed, exclude the domain from the signature. See the "Running a Python URL Signing Script" section for more information. The URL validation must not include the domain for validation (use the exclude-domain option for the exclude-validate attribute of the Rule_Validate element).

SrcIp

   

Matches the source IP address and netmask of the request.

UrlRegex

   

Matches the URL against a regular expression. The match is case sensitive.

Rule_Actions

Rule_Allow
Rule_Block
Rule_Validate
R
ule_UrlRewrite
Rule_NoCache

 

The rules are processed in the same order they are listed in the Rule_Actions element.

Multiple Rule_Actions can be configured; for example, there can be a Rule_Allow followed by a Rule_Block followed by a Rule_UrlRewrite and so on. The Rule_Actions can be in any order and the processing of the rules is determined by the order they are listed in the Service Rule XML file.

You can have multiple instances of the same Rule_Actions subelement Rule_UrlRewrite; the last Rule_UrlRewrite with a matched condition is the rule that is applied. For all other Rule_Actions subelement types, it is not recommended to have multiple entries because the pattern matching is based on the pattern groups listed and multiple instances of the same rule for the listed pattern groups would give the same results.

The following list describes the Rule_Actions processing:

When a Rule_Allow pattern is matched, the request is allowed, and if there are subsequent rules, the next Rule_Actions is processed. If the condition is not matched, the request is denied and no further rule processing is performed.

When a Rule_Block pattern is matched, the request is blocked and the Rule_Actions processing does not continue.

When a Rule_Validate pattern is matched, the request is validated and if the validation is successful, the Rule_Actions processing continues to the next rule configured. If the validation fails, the request is not validated and the Rule_Actions processing stops.

Whether a Rule_UrlRewrite pattern is matched or not, rule processing continues to the next configured rule. If the Rule_UrlRewrite pattern is matched, the request is rewritten. If the Rule_UrlRewrite pattern is not matched, the request is not rewritten.

Whether a Rule_NoCache pattern is matched or not, rule processing continues to the next configured rule. Rule_NoCache action just determines whether to cache the content on the SE or not, provided further rule processing results in the request being allowed. If the Rule_NoCache pattern is matched, the content is not cached on the SE. If the Rule_NoCache pattern is not matched, the content is cached on the SE.

Note The Rule_NoCache subelement is only supported in Release 2.5.9.

Rule_Allow

 

matchGroup
protocol

The matchGroup attribute value is the list of PatternListGrp id attributes. The protocol attribute value must be http.

Note Only http is supported as the protocol attribute value in Release 2.5.7 and later releases. All other values have no effect.

Rule_Block

 

matchGroup
protocol

The matchGroup attribute value is the list of PatternListGrp id attributes. The protocol attribute value must be http.

Note Only http is supported as the protocol attribute value in Release 2.5.7 and later releases. All other values have no effect.

Rule_Validate

 

matchGroup
protocol
error-redirect-url
exclude-validation

The matchGroup attribute value is the list of PatternListGrp id attributes. The protocol attribute value must be http.

Note Only http is supported as the protocol attribute value in Release 2.5.7 and later releases. All other values have no effect.

The error-redirect-url attribute value is the URL that clients are redirected to if they fail validation.

The exclude-validation attribute is optional and can be one of the following values: client-ip, expiry-time, exclude-domain, or all.

The exclude-validation client-ip attribute instructs the SEs to ignore the client's IP address when processing the validation of the signed URL.

The exclude-validation expiry-time attribute instructd the SEs to ignore the expiry time that normally limits access to the content when the expiry time has occurred.

The exclude-validation exclude-domain attribute instructs the SEs to ignore the domain in the URL when processing the validation of the signed URL.

The exclude-validation all attribute instructs the SEs to ignore both the client IP address and the content expiration time when processing the validation of the signed URL.

Note The exclude-domain option is a Release 2.5.9 feature.

Rule_UrlRewrite

 

matchGroup
protocol
rewrite-url
regsub

The matchGroup attribute value is the list of PatternListGrp id attributes. The protocol attribute value must be http.

Note Only http is supported as the protocol attribute value in Release 2.5.7 and later releases. All other values have no affect.

The rewrite-url attribute value is the URL used to rewrite the original request.

The regsub attribute value is the regular expression the request URL must match to be replaced with the rewrite-Url attribute value. The regsub attribute value must be an exact match of the string you want to replace in the request URL.

Note In Release 2.5.9 and later releases, the regsub attribute supports regular expressions, but only one substitution can be defined. Multiple substitutions are not supported.


All specified attributes for the Rule_Actions subelements are required, except the exclude-validation attribute, which is optional. For more information about service rules, see the "Configuring Service Rules" section.

Boolean AND and OR Function

When a PatternListGrp is specified for an action, it implies an AND of all the patterns within the group. All patterns specified in that group must be matched for the action to take place.

<Rule_Patterns>
    <PatternListGrp id = "grp1">
        <UrlRegex>videos</UrlRegex>
        <Domain>rfqdn.cds.com</Domain>
    </PatternListGrp>
</Rule_Patterns>
 
   
<Rule_Actions>
        <Rule_UrlRewrite matchGroup = "grp1" protocol = "http" regsub = "videos" 
rewrite-url = "http://dummy.cds.com" />
</Rule_Actions>
 
   

When the matchGroup id attributes are separated by a comma, it implies an OR of all the patterns. The action is taken when either of the patternListGrp elements are matched.

<Rule_Actions>
        <Rule_Allow matchGroup = "grp1,grp5" protocol = "http" />
</Rule_Actions>
 
   

Service Rule XML Schema

The XML Schema file describes and dictates the content of the XML file. The CDSRules.xsd file contains the XML schema. The following code is the Service Rule XML schema:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:annotation>
		<xsd:documentation> Revision: 1.0 </xsd:documentation>
	</xsd:annotation>
	<xsd:annotation>
		<xsd:documentation> Schema used to validate Cisco CDS Rules file 
</xsd:documentation>
	</xsd:annotation>
	<xsd:element name="CDSRules">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Revision" type="xsd:string" minOccurs="0" 
maxOccurs="1"/>
				<xsd:element name="CustomerName" type="xsd:string" minOccurs="0" 
maxOccurs="1"/>
				<xsd:element ref="Rule_Patterns"/>
				<xsd:element ref="Rule_Actions"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>
	<!-- Section to validate Actions -->
	<xsd:element name="Rule_Actions">
		<xsd:complexType>
            <xsd:choice minOccurs="1" maxOccurs="unbounded">
				<xsd:element ref="Rule_Allow" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="Rule_Block" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="Rule_Validate" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="Rule_UrlRedirect" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="Rule_UrlRewrite" minOccurs="0" maxOccurs="unbounded"/>
		    </xsd:choice>
        </xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_Allow">
		<xsd:complexType>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_Block">
		<xsd:complexType>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_Validate">
		<xsd:complexType>
			<xsd:attribute name="exclude-validation" type="validateActionExcludeType" 
use="optional"/>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="error-redirect-url" type="UrlType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_UrlRedirect">
		<xsd:complexType>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="redirect-url" type="UrlType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_UrlRewrite">
		<xsd:complexType>
			<xsd:attribute name="regsub" type="UrlType" use="required"/>
			<xsd:attribute name="rewrite-url" type="UrlType" use="required"/>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="Rule_NoCache">
		<xsd:complexType>
			<xsd:attribute name="matchGroup" type="matchGroupType" use="required"/>
			<xsd:attribute name="protocol" type="protocolType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<!-- If CdsGrp2 | CdsGrp2 , cpp validator witll take it only once as CdsGrp2 -->
	<xsd:simpleType name="matchGroupType">
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="[A-Za-z0-9]{1,128}(,[A-Za-z0-9]{1,128})*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="protocolType">
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="http"/>
			<!-- todo -->
			<!-- http | rtsp | rtmp | rtmpe | rtmpt | rtmpte | all -->
			<!--
			<xsd:pattern value="(http | rtsp | rtmp | rtmpe | rtmpt | rtmpte | all) (| 
[http | rtsp | rtmp | rtmpe | rtmpt | rtmpte | all])* "/>
			<xsd:pattern value="(http | ) | (rtsp | ) | (rtmp | ) | (rtmpe | ) | (rtmpt | 
) | (rtmpte | ) | (all | )"/>
			<xsd:pattern value="a | b | c"/>
			<xsd:pattern value="\b(http|rtsp|rtmpte|rtmpe|rtmpt|rtmp|all)\b"/>
			-->
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="validateActionExcludeType">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="client-ip"/>
			<xsd:enumeration value="expiry-time"/>
			<xsd:enumeration value="exclude-domain"/>
			<xsd:enumeration value="all"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- todo url validate -->
	<xsd:simpleType name="UrlType">
		<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<!-- Section to Validate Patterns -->
	<xsd:element name="Rule_Patterns">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="PatternListGrp" maxOccurs="unbounded"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="PatternListGrp">
		<xsd:complexType>
            <xsd:choice maxOccurs="unbounded">
				<xsd:element ref="Domain" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="Header" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="SrcIp" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element ref="UrlRegex" minOccurs="0" maxOccurs="unbounded"/>
			</xsd:choice>
            <xsd:attribute name="id" type="PatternListGroupIdType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<!-- RFC1034 - only letters, digits, '-' and '.' are allowed in domainname -->
	<xsd:element name="Domain">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string"/>
		</xsd:simpleType>
	</xsd:element>
	<xsd:element name="Header">
		<xsd:complexType>
			<xsd:attribute name="name" type="HeaderNameType" use="required"/>
			<xsd:attribute name="value" type="HeaderValueType" use="required"/>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="UrlRegex">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string"/>
		</xsd:simpleType>
	</xsd:element>
	<!-- Simple types for Pattern -->
	<!-- todo need unique value of patterngroupid -->
	<xsd:simpleType name="PatternListGroupIdType">
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="[A-Za-z0-9]{1,128}"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="HeaderNameType">
		<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<xsd:simpleType name="HeaderValueType">
		<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<xsd:element name="SrcIp">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string">
			</xsd:restriction>
		</xsd:simpleType>
		</xsd:element>
	<xsd:simpleType name="SrcIpType">
		<xsd:union>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/[0-9]
+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){7}/[0-9]+"/>
				</xsd:restriction>
				<!-- IPv6-full = IPv6-hex 7(":" IPv6-hex) -->
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){5}::([A-Fa-f0-9]{1,4})?/[0-9]+"/>
				</xsd:restriction>
				<!-- IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" 
IPv6-hex)] -->
				<!-- An "::" represents at least 2 16-bit groups of zeros -->
				<!-- No more than 6 groups in addition to the "::" may be present. -->
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){4}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4})?)?/[0-
9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){3}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,2})?
/[0-9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){2}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,3})?
/[0-9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}:[A-Fa-f0-9]{1,4}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,4})?/[0-9
]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,4})?/[0-9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){5}:(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\
.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\
.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))/[0-9]+"/>
				</xsd:restriction>
				<!-- IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal -->
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){3}::([A-Fa-f0-9]{1,4}:)?(((1?[1-9])?[0-9])|(2[0
-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0
-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))/[0-9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){2}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4})?:)?(((
1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((
1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))/[0-9
]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}:[A-Fa-f0-9]{1,4}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,2}:)?(((1
?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1
?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))/[0-9]
+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType>
				<xsd:restriction base="xsd:token">
					<xsd:pattern 
value="[A-Fa-f0-9]{1,4}::([A-Fa-f0-9]{1,4}(:[A-Fa-f0-9]{1,4}){0,2}:)?(((1?[1-9])?[0-9])|(2
[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2
[0-4][0-9])|(25[0-5]))\.(((1?[1-9])?[0-9])|(2[0-4][0-9])|(25[0-5]))/[0-9]+"/>
				</xsd:restriction>
			</xsd:simpleType>
			<!-- IPv4 Address -->
			<!-- Snum = 1*3DIGIT  ; representing a decimal integer -->
			<!--                  ; value in the range 0 through 255 -->
			<!-- IPv4-address-literal = Snum 3("." Snum) -->
			<!-- IPv6 Address -->
			<!-- IPv6-hex  = 1*4HEXDIG -->
			<!-- IPv6-full = IPv6-hex 7(":" IPv6-hex) -->
			<!-- IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"IPv6-hex)] 
-->
			<!--             ; The "::" represents at least 2 16-bit groups of zeros -->
			<!--             ; No more than 6 groups in addition to the "::" may be 
present -->
			<!-- IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal -->
			<!-- IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) 
":"] IPv4-address-literal -->
			<!--             ; The "::" represents at least 2 16-bit groups of zeros -->
			<!--             ; No more than 4 groups in addition to the "::" and 
IPv4-address-literal may be present -->
			<!-- IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp -->
		</xsd:union>
	</xsd:simpleType>
</xsd:schema>
 
   

Service Rule File Example

The following is an example of the Service Rule file example.

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
    <Revision>1.0</Revision>
    <CustomerName>Capricious</CustomerName>
    <Rule_Patterns>
        <PatternListGrp id = "grp1">
                <UrlRegex>videos</UrlRegex>
                <Domain>rfqdn.cds.com</Domain>
        </PatternListGrp>
        <PatternListGrp id = "grp2">
            <Domain>dummy.cds.com</Domain>
            <SrcIp>10.10.10.10</SrcIp>
        </PatternListGrp>
        <PatternListGrp id = "grp3">
            <SrcIp>10.21.148.231</SrcIp>
        </PatternListGrp>
        <PatternListGrp id = "grp5">
		<UrlRegex>/*</UrlRegex>
        </PatternListGrp>
        <PatternListGrp id = "grp6">
            <Domain>rfqdn.cds.com</Domain>
        </PatternListGrp>
    </Rule_Patterns>
    <Rule_Actions>
        <Rule_Allow matchGroup = "grp1,grp5" protocol = "http"  />
        <Rule_UrlRewrite matchGroup = "grp1" protocol = "http" regsub = "videos" 
rewrite-url = "http://dummy.cds.com" />
        <Rule_Block matchGroup = "grp3" protocol = "http" />
        <Rule_Validate matchGroup = "grp5"  protocol = "http" error-redirect-url = 
"http://wwwin.cisco.com" exclude-validation = "all" />
    </Rule_Actions>
</CDSRules>

Service Rule File for URL Validation and the Exclude-Validation Attribute

As part of the URL Signing feature, to validate signed URLs for the Web Engine, you must configure the Service Rule file for URL Validation. The exclude-validation attribute offers the option to exclude the client IP address, the expiry time, or both from the URL validation process. The following sections explain the different exclude validation options:

Exclude Client IP Address from URL Validation

Exclude Expiry Time from URL Validation

Exclude Both the Client IP Address and the Expiry Time from URL Validation

Exclude Client IP Address from URL Validation

While performing URL validation, the SE compares the IP address from which it received the request and the CIP field in the signed URL request. The client IP address is a required parameter and is displayed as the CIP field in the signed URL request. If you configure the exclude-validation attribute with the client-ip value in the Service Rule XML file, the URL validation process ignores the client IP address during the validation process.

Following is an example of the Service Rule XML file with the exclude-validation attribute set to client-ip:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
 <Revision>1.0</Revision>
 <CustomerName>ATT</CustomerName> 
 <Rule_Patterns>
  <PatternListGrp id = "grp1">
   <Domain>iphone.com</Domain>
  </PatternListGrp>
 </Rule_Patterns>
 <Rule_Actions>
  <Rule_Validate matchGroup = "grp1" protocol="http" exclude-validation="client-ip" error-redirect-url = "http://wwwin.cisco.com"/>
 </Rule_Actions>
</CDSRules>
 
   

Exclude Expiry Time from URL Validation

Without the exclude-validation expiry-time attribute, he generated URL would be valid only for a stipulated period of time mentioned at the time of signing. This is indicated in the ET field in the signed URL. The ET field value is generated with respect to the local time on the server used for signing. The expriy time relies on the synchronization of the devices; for more information, see the "Importance of Device Synchronization" section.

On receiving the request, the URL validation process compares the time stamp on the SE with the time stamp in the ET field of the received request. If the time stamp on the request is less than the time stamp on the SE, the request is rejected because of the expiry time lapse.

To bypass the expiry time validation, use the exclude-validation attribute with the expiry-time value in the Service Rule XML file.

Following is an example of the Service Rule XML file with the exclude-validation attribute set to expiry-time:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
 <Revision>1.0</Revision>
 <CustomerName>ATT</CustomerName> 
 <Rule_Patterns>
  <PatternListGrp id = "grp1">
   <Domain>iphone.com</Domain>
  </PatternListGrp>
 </Rule_Patterns>
 <Rule_Actions>
   <Rule_Validate matchGroup = "grp1" protocol="http" exclude-validation="expiry-time" error-redirect-url = "http://wwwin.cisco.com"/>
 </Rule_Actions>
</CDSRules>
 
   

Exclude Both the Client IP Address and the Expiry Time from URL Validation

The exclude-validation attribute with the all value excludes both the client-ip and the expiry-time from the URL validation process. Meaning the SE considers the request successful even if the request comes from a different client than what is mentioned in the signed URL and the expiry-time has lapsed.

Following is an example of the Service Rule XML file with the exclude-validation attribute set to all:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
 <Revision>1.0</Revision>
 <CustomerName>ATT</CustomerName> 
 <Rule_Patterns>
  <PatternListGrp id = "grp1">
   <Domain>iphone.com</Domain>
  </PatternListGrp>
 </Rule_Patterns>
 <Rule_Actions>
  <Rule_Validate matchGroup = "grp1" protocol="http" exclude-validation="all" error-redirect-url = "http://wwwin.cisco.com"/>
 </Rule_Actions>
</CDSRules>

Note The exclude-validate attribute with the exclude-domain value is supported in Release 2.5.9. The exclude-validation exclude-domain attribute instructs the SEs to ignore the domain in the URL when processing the validation of the signed URL.