URL Resource Pattern Matching

URL resource pattern matching was greatly enhanced with the Cams server 1.5 release. This Cams tip explains how the new URL resource pattern matching works and provides some practical examples.

Overview

The bread and butter of a Cams security policy is found in each security domain's access-control-policy.xml file. This file defines a series of access control permissions, which map resources to the access control rules that protect them. Example 1 shows an XML snippet defining an http permission. In this example, the My Secure Directory Rule would be applied to any request for a resource in the www.mycompany.com:80 server's mySecureDirectory directory.

<permission desc="My Secure Directory Rule" actions="GET,POST"> 
 <resource-pattern id="http://www.mycompany.com:80/mySecureDirectory/*"/>
 <acr-ref id="My Secure Directory Rule"/>
</permission>

Example 1 - Simple Cams permission example

Each Cams http permission must specify a URL resource pattern. When an http access control request is received by the Cams server, the list of URL resource patterns is searched to find the best match. Once selected, the permission's corresponding rule (specified by the acr-ref attribute) is used to determined if the request will be granted or denied access. Alternatively, the permission may delegate the request to another security domain.

The recommended practice is to make a URL resource pattern just general enough to match all the resources that must be protected by the same access control rule (or delegated to the same security domain). This enables you to minimize the number of permissions needed by your access control policy. Remember, simplicity is golden when security is involved.

URL-based Resource Sub-Patterns

URL resource patterns include a lot of flexibility and some limitations. In particular, use of the wildcard character '*' is supported only in certain contexts, which helps maximize performance and simplify the rules for best permission matching. The meaning of '*' depends on the part of the URL pattern in which it is used. URL resource patterns are composed of four sub-patterns:

shemePattern :// hostPattern : portPattern / uriPattern

where:

• scheme - resource type, currently either http or cams
• host - IP address or DNS hostname for the server where the resource is located
• port - the port number on which the server listens for client connections
• URI - the path on the server to the resource

Each sub-pattern has its own validation rules. The best matching pattern is based on URI first, port second, host third, and scheme last. Cams implements resource pattern scoring based on field weighting and field pattern specificity to ensure that more specific patterns are matched. Example 2 summarizes the legal URL resource sub-patterns.

Example 2 - URL Resource Pattern Sub-Pattern Examples

Example Resource Patterns

Each sub-pattern within the overall resource pattern may be customized independently to make it as specific or as general as needed. Example 3 shows some general examples of patterns that you can use.

Example 3 - Sample Resource Patterns

Moving Security Policies Between Servers

Prior to Cams 1.5 you were required to specify the exact scheme, host, and port values for a URL resource pattern. This required a different resource pattern (and consequently a different permission) for each web server on which you wanted to protect a similar URL (which varied only by host and/or port). With Cams 1.5, you can now use the same security policy across multiple servers using the "*" wildcard character with the scheme, host, and port sub-patterns. For example, you might use a URL resource pattern such as:

*://*:*/mySecureResource/*

This URL resource pattern would secure the mySecureResource directory with the associated rule on any server, regardless of the hostname and port. Similarly, but perhaps providing tighter security would be:

*://*.mydomain.com:*/mySecureResouce/*

This URL resource pattern would only match for hosts within the mydomain.com domain.

Putting some Bite into the Cams Confidential Rule

The intrinsic Cams confidential rule enables you to grant or deny access based upon the confidentiality of the network connection. If the confidential rule is used, the request must use a secure SSL/TLS connection (a.k.a., HTTPS) to access a resource. Because you previously had to explicitly specify the URL resource pattern scheme (http or https), this rule was limited in usefulness. Also, you often needed to have redundant rules for HTTP and HTTPS resources. Now, you can use the wildcard for the scheme sub-pattern to grant or deny access based upon confidentiality. Consider the following URL resource pattern and associated rule, which only grants access to managers using a secure connection:

<permission-collection type="http" desc="HTTP/HTTPS resource permissions">

 <permission desc="Require Manager Confidentially" actions="GET,POST"> 
  <resource-pattern id="*://www.mycompany.com:*/mySecureDirectory/*"/>
  <acr-ref id="confidential manager rule"/>
 </permission>

</permission-collection>

<acr-lib>

 <auth-acr id="allow manager">
  <role-constraint>
   <role-name>manager</role-name>
  </role-constraint>
 </auth-acr>

 <acr id="confidential manager rule">
  <acr-ref id="confidential"/>
  <and/>
  <acr-ref id="allow manager"/>
 </acr>

</acr-lib>

Example 4 - Sample permission that only grants access to an authenticated manager using a HTTPS

In addition, using a wildcard for the scheme ensures that the permission will be enforced for both HTTP and HTTPS requests. Generally, use of the wildcard for the scheme is recommended.

Additional Reading

To learn more about Cams access control, please reference the following documents:

• Cams Administrator's Guide - Access Control Services
• Cams Administrator's Guide - Access Control Policy Tag Reference