Resource Policy Overview
When you enable the Web access feature for a role, you need to create resource policies that specify which resources a user can access, whether or not to rewrite the content requested by the user, and caching, applet, or single sign-on requirements. For every Web request, the system first evaluates the rewriting policies you configure. If the user's request is to a resource specified as "don't rewrite" due to either a selective rewriting or passthrough proxy resource policy, then forward the user's request to the appropriate back-end resource. Otherwise, the system continues to evaluate those resource policies corresponding to the request, such as Java resource policies for a request to fetch a Java applet. After matching a user's request to a resource listed in a relevant policy, the system performs the action specified for the resource.
You can create resource policies through the standard interface (as described in this section) or through resource profiles (recommended method).
When writing a Web resource policy, you need to supply key information:
•Resources - A resource policy must specify one or more resources to which the policy applies. When writing a Web policy, you need to specify Web servers or specific URLs, as explained in the section that follows.
•Roles - A resource policy must specify the roles to which it applies. When a user makes a request, the system determines what policies apply to the role and then evaluates those policies that correspond to the request.
•Actions - Each type of resource policy performs a certain action, which is either to allow or deny a resource or to perform or not perform some function, such as rewrite content, re-sign an applet, or post Web data. You can also write detailed rules that apply more conditions to a user request.
The system platform's engine that evaluates resource policies requires that the resources listed in a policy's Resources list follow a canonical format.
Canonical Format
This section outlines special considerations you must consider when specifying a Web resource using the canonical format.
•[protocol://]host[:ports][/path]
The four components are:
•Protocol (optional) - Possible values: http and https (case-insensitive)
If the protocol is missing, then both http and https are assumed. If a protocol is specified, then the delimiter "://" is required. No special characters are allowed.
•Host (required) - Possible values:
•DNS Hostname - For example: www.pulsesecure.net
Allowed special characters are described in the following table.
DNS Hostname Special Characters
|
* |
Matches ALL characters |
|
% |
Matches any character except dot (.) |
|
? |
Matches exactly one character |
•IP address/Netmask - The IP address needs to be in the format: a.b.c.d
The netmask can be in one of two formats:
•Prefix: High order bits
•IP: a.b.c.d
For example: ÌPv4 format: 10.11.149.2/24 or 10.11.149.2/255.255.255.0;
IPv6 format: [2001:db8:a0b:12f0::1/64]:80,443/public/*
[2001:db8:a0b:12f0::1/64]:8000-9000/*
No special characters are allowed.
•Ports - You must specify a port when specifying IP/netmask as a resource. The port is optional when specifying a DNS hostname. If a port is specified, then the delimiter ":" is required. For example: 10.11.149.2/255.255.255.0:* The following table lists the possible port values.
|
* |
Matches ALL ports; no other special characters are allowed |
|
port[,port]* |
A comma-delimited list of single ports. Valid port numbers are [1-65535]. |
|
[port1]-[port2] |
A range of ports, from port1 to port2, inclusive. |
You can mix port lists and port ranges, such as: 80,443,8080-8090
If the port is missing, then the default port 80 is assigned for http, 443 for https.
•Path (optional)-If the path is missing, then star (*) is assumed, meaning ALL paths match. If a path is specified, then the delimiter "/" is required. No other special characters are supported. For example:
•http://www.pulsesecure.net:80/*
•https://www.pulsesecure.net:443/intranet/*
•*.yahoo.com:80,443/*
•%.danastreet.net:80/share/users/<username>/*