Access Control Policy Tag Reference

A Cams access control policy declares web resources and the access control rules that secure them using a security domain specific XML file, access-control-policy.xml. Web resources are declared in permissions that are grouped within permission collections. Access control rules are declared within an access control rule library.

This document contains reference information for each of the XML tags that can be used within a Cams access-control-policy.xml file to implement an access control policy. Table 1 shows the hierarchical file structure of this file with convenience links to each of the standard Cams access control XML elements. This document is also organized into the following sections:

• Access Control Policy
• Permission Collections
• Access Control Rule Library
• Access Control Rule Expressions
• Authentication Access Control Rule
• Authentication Method Access Control Rule
• Host Access Control Rule
• Attribute Access Control Rule
• Obligations Access Control Rule
• SQL Data Access Control Rule
• Custom Access Control Rule

Table 1 - Hierarchical links to the standard Cams access-control-policy.xml file XML elements

Access Control Policy

An access control policy contains all the rules and permissions that govern access to web resources secured by Cams. Access control policies are specific to a security domain and defined in an XML file, access-control-policy.xml. Each HTTP request creates an access check request, which is evaluated against the Cams access control policy to return a grant or deny decision. All access check requests are first evaluated by the system security domain's access control policy, which may delegate request to another security domain.

<access-control-policy>

The top-level element for an access control policy.

<access-control-policy 
  lastModified="date/time value" 
  defaultBias="granted|denied"
  debug="true|false">
  ...
</access-control-policy> 

Permission Collections

A security domain's access control policy contains one permission collection for each unique type of permission it supports. For example, all HTTP protocol permissions are stored in a single HTTP-specific permission collection. Permission collections organize Cams access control policies by protocol and optimize access control performance.

<permission-collection>

A type-specific collection of permissions. Any number of permission-collections may exist within an access control policy, but each must have a unique type. Currently, http (used for all HTTP protocol access check requests) or cams (used for Cams protocol access check requests) are defined by default. However, Cams agents can be embedded into other types of network software, which when associated with a permission collection/permission type would enable Cams to secure other protocols (e.g. SOAP to support securing web services).

<permission-collection 
  type="type code" 
  desc="textual description"
  debug="true|false">
  ...
</permission-collection> 

<permission-collection type="http" desc="HTTP Resource Permissions">

  <!--=================================-->
  <!-- Intrinsic Permission Examples   -->
  <!--=================================-->

  <!-- Grant access to the Cams login/logout URIs and the Cams login,
       denied and error pages. 
         
       WARNING: You MUST grant access to these Cams resources or the 
       user will not be able to login/logout or be redirected
       to the error or denied pages. -->
  <permission desc="Cams IIS/J2EE login, denied and error pages" actions="GET,POST">
    <resource-pattern id="*://*:*/cams*"/>
    <acr-ref id="granted"/>
  </permission>

  <!-- Require confidential connections for Cams login resources -->
  <permission desc="Cams login resources require confidential connection">
    <resource-pattern id="*://*:*/cams/login*"/>
    <acr-ref id="confidential"/>
  </permission>

  <!-- Grant HTTP "GET" access to public resources -->
  <permission desc="Public web resources" actions="GET"> 
    <resource-pattern id="*://*:*/*"/>
    <acr-ref id="granted"/>
  </permission>

  <!-- Deny access to system configuration files -->
  <permission desc="Deny direct access to configuration files">
    <resource-pattern id="*://*:*/*.conf"/>
    <acr-ref id="denied"/>
  </permission>

  <!-- Delegate resources to the "myCompany" security domain        

         WARNING: This will not load correctly unless a "myCompany"          
         security domain is defined. -->
  <permission desc="mycompany web resources"> 
    <resource-pattern id="*://www.mycompany.com:*/*"/>
    <owner id="mycompany"/>
  </permission>

  <!-- Unconditionally grant access to images under employee resources -->
  <permission desc="Grant access to employee images" actions="GET">
    <resource-pattern id="*://*:*/employee/images*"/>
    <acr-ref id="granted"/>
  </permission>

  <!--=================================-->
  <!-- Auth Permission Examples        -->
  <!--=================================-->

  <!-- Resources available only to authenticated employees -->
  <permission desc="Employee web resources"> 
    <resource-pattern id="*://*:*/employee*"/>
    <acr-ref id="complex employee rule"/>
  </permission>

  <!-- Grant access to images under employee resources -->
  <permission desc="Grant access to employee images" actions="GET">
    <resource-pattern id="*://*:*/employee/images*"/>
    <acr-ref id="granted"/>
  </permission>

  <!--=================================-->
  <!-- Host Permission Examples        -->
  <!--=================================-->

  <!-- Resources available only when using any LAN host -->
  <permission desc="All LAN hosts can access internal resources">          
    <resource-pattern id="*://*:*/internal*"/>
    <acr-ref id="lan rule"/>
  </permission>

  <!-- Resources available only when using a specific WAN hosts -->
  <permission desc="Specific WAN hosts can access partner resources">          
    <resource-pattern id="*://*:*/partner*"/>
    <acr-ref id="wan rule"/>
  </permission>

  <!--=================================-->
  <!-- Auth/Host Permission Examples   -->
  <!--=================================-->

  <!-- Resources available only when authenticated as an "administor"          
       from any LAN host -->
  <permission desc="Administrator resources that can only be access from LAN"> 
    <resource-pattern id="*://*:*/admin*"/>
    <acr-ref id="administrator lan rule"/>
  </permission>

  <!--=================================-->
  <!-- Attribute Permission Example    -->
  <!--=================================-->

  <!-- ReportBuilder historical reports are only available to shareholders
       for specific report types and years. -->
  <permission desc="Administrator resources that can only be access from LAN"> 
    <resource-pattern id="*://*:*/ReportBuilder/gethistorical.do"/>
    <acr-ref id="shareholder reportbuilder rule"/>
  </permission>

  <!--=================================-->
  <!-- Obligations Permission Example  -->
  <!--=================================-->

  <!-- Users must be authenticated with the "PASSWORD" authentication method
       to update their profiles. -->
  <permission desc="Users must authenticate with user name and password for self-administration"> 
    <resource-pattern id="*://*:*/CamsIdentity/selfAdmin*"/>
    <acr-ref id="obligate authenticated user with password authentication method rule"/>          
  </permission>

  <!--=================================-->
  <!-- SQL Data Permission Example     -->
  <!--=================================-->

  <!-- Users must be authenticated and have completed information in the user
       database table COMPANY field. -->
  <permission desc="Users must authenticate with user name and password for self-administration"> 
    <resource-pattern id="*://*:*/whitepapers*"/>
    <acr-ref id="authenticated user with completed company rule"/>
  </permission>

  <!--=================================-->
  <!-- Custom Rule Permission Examples -->
  <!--=================================-->

  <!-- Resources available during business hours -->
  <permission desc="Live support is only available during business hours"> 
    <resource-pattern id="*://*:*/livesupport*"/>
    <acr-ref id="business hours rule"/>
  </permission>

  <!-- Resources only available to authenticated users with gold accounts -->
  <permission desc="Gold account resources only available to users with gold accounts"> 
    <resource-pattern id="*://*:*/goldaccount*"/>
    <acr-ref id="account type rule"/>
  </permission>

</permission-collection>

<permission>

A type-specific resource and rules for controlling access. A permission identifies a set of resources via a resource pattern and either an access control rule to evaluate or the owner of another security domain to which access control will be delegated. Any number of permissions may be added to a permission-collection provided the resource pattern and action(s) are valid for the enclosing permission collection and the permissions don't overlap. Permissions overlap if their fully-qualified resource patterns are identical and they have at least one action in common. An access control policy referencing an overlapping permission will fail to load.

<permission 
  desc="textual description"
  actions"GET,POST,PUT,DELETE,HEAD,OPTIONS,TRACE | ACCESS, START, STOP"
  debug="true|false">
  ...
</permission> 

<resource-pattern>

Identifies the resources associated with a permission. When a permission receives an access control request, it compares the requested resource and action against it's identifer and actions patterns. If the patterns match and are the most specific for the request, then the permission will be used to enforce access control.

<resource-pattern id="resource pattern"/>

<acr-ref>

A reference to an existing access control rule within the enclosing security domain's access control rule library. Access control rules can be referenced from:

1. permissions to assign the access control rule that protects matching resources
2. other access control rule expressions to be create (composite) custom access control rules

The referenced access control rule must already have been defined within the access control library or an Undefined Access Control Rule will be reported.

<acr-ref id="access control rule identifier reference"/>

<owner>

A reference to an existing security domain (other than system) to which access control for a permission is delegated.

<owner id="security domain name"/>

Access Control Rule Library

An access control rule library is a container for defining all access control rules available within a security domain. There is only one access control rule library for each security domain. Access control rules defined in one security domain may not be referenced from another security domain.

<acr-lib>

A container for all security domain access control rule types and references.

<acr-lib debug="true|false">
  ...
</acr-lib> 

<acr-lib>

  <!--======================================-->
  <!-- Host Access Control Rule Examples    -->
  <!--======================================-->

  <!-- Allow hosts where: 
       1) the remote host has an IP address that matches 
          pattern "192.168.0.*" -->
  <host-acr id="lan rule">
    <allow-address>
      <address>192.168.0.*</address>
    </allow-address>
  </host-acr>

  <!-- Allow hosts where: 
       1) the remote host has a name that ends with 
          ".mycompany.com" or ".partner.com" 
       2) but the remote host does not include "badcompany.com"
       3) or the remote host has IP address "208.175.100.5"
       4) or the remote host has an IP address that matches 
          pattern "192.168.0.*"
       5) but the remote host does not have IP address "203.142.0.101" -->
  <host-acr id="wan rule">

    <allow-host>
      <host>*.mycompany.com</host>
      <host>*.partner.com</host>
    </allow-host>

    <deny-host>
      <host>*badcompany.com</host>
    </deny-host>

    <allow-address>
      <address>208.175.100.5</address>
      <address>192.168.0.*</address>
    </allow-address>

    <deny-address>
      <address>203.142.0.101</address>
    </deny-address>

  </host-acr>

  <!--======================================-->
  <!-- Auth Access Control Rule Examples    -->
  <!--======================================-->

  <!-- Cams agents must have the "cams-agent" role -->
  <auth-acr id="cams agent rule">
    <role-constraint>
      <role-name>cams-agent</role-name>
      <role-class>com.cafesoft.cams.auth.CSRolePrincipal</role-class>
    </role-constraint>
  </auth-acr>

  <!-- Require an authenticated user to have "employee" role -->
  <auth-acr id="simple employee rule">
    <role-constraint>
      <role-name>employee</role-name>
    </role-constraint>
  </auth-acr>

  <!-- Allow only if:
       1) the user is authenticated
       2) and the user has the "administrator" role
       3) or the user has the "employee" role
       4) and the user does not have the "contractor" role, 
          implemented by a specific Java class 

       An auth-acr will evaluate to "true" ONLY if: 
       1) the user is authenticated and at least one role- 
          constraint matches a user role and no role-constraints 
          deny access
       2) the user is authenticated and auth-acr is completely 
          empty of role-constraints -->
  <auth-acr id="complex employee rule">
    <role-constraint>
      <role-name>administrator</role-name>
    </role-constraint>
    <role-constraint>
      <role-name>employee</role-name>
    </role-constraint>
    <role-constraint accessGranted="false">
      <role-name>contractor</role-name>
      <role-class>com.cafesoft.cams.auth.CSRolePrincipal</role-class>
    </role-constraint>
  </auth-acr>

  <!-- Require an authenticated user to have "administrator" role,
       which must be implemented by a specific role class -->
  <auth-acr id="administrator rule">
    <role-constraint>
      <role-name>administrator</role-name>
      <role-class>com.cafesoft.cams.auth.CSRolePrincipal</role-class>
    </role-constraint>
  </auth-acr>

  <!-- Require:
       1. the host to be on the LAN
       2. the user to be authenticated with "administrator" role
       3. a confidential (SSL) connection for privacy -->
  <acr id="administrator lan rule">
    <acr-ref id="lan rule"/>
    <and/>
    <acr-ref id="administrator rule"/>
    <and/>
    <confidential/>
  </acr>

</acr-lib>

<acr-type>

Declares a custom type of access control rule within an access control rule library. Once defined, access control rules can be used within the access control rule library directly or nested within an access control rule expression. This tag registers new access control rule types created using the Cams Access Control Rule API. See the Cams Programmer's Guide - Access Control Rules for more details.

<acr-type>
  ...
</acr-type> 

<!-- Declare a custom access control rule type for limiting
     access by company business hours -->
<acr-type			
   name="example:business-hours-acr"			
   className="examples.acrs.BusinessHoursAcr"
   desc="Control access by normal business hours">
   <acr-persistence-manager className="examples.acrs.XmlBusinessHoursAcrPm">
      <param-list>
         <param name"clockHours" value="0-23"/>
         <param name="useLocalTimeZone" value="true"/>
      </param-list>
   </acr-persistence-manager>
</acr-type>

<acr-persistence-manager>

Configures the Java class that is responsible for storing, loading, and creating new access control rules.

<acr-persistence-manager debug="true|false">
  ...
</acr-persistence-manager> 

<param-list>

An optional list of parameters that can be used to set the default configuration.

<param-list>
  ...
</param-list>

<param>

A parameter used to set the default configuration.

<param name="textual name" value="value"/>

Access Control Rule Expressions

Access control rule expressions are rules declared by referencing other existing rules with boolean operators that specify any conditional logic. For example, you can use an access control rule expression to create access control rules such as Only allow access to users with role administrator while using hosts on LAN during business hours.

<acr>

Creates a custom access control rule by combining other element attributes. Once defined, access control rule expressions can be referenced directly from permissions or nested within other access control rule expressions using the acr-ref element.

<acr 
  id="access control rule identifier" 
  debug="true | false">
  ...
</acr>

<granted> <denied> <confidential>

Instrinsic access control rules available to all security domains and referenced by their identifiers:

• granted - unconditionally grant access to a resource
• denied - unconditionally deny access to a resource
• confidential - require a confidential connection (usually SSL/TLS)

<granted/>
<denied/>
<confidential/>

<and> <or> <not>

Boolean operators embedded in access control rule expressions that define logical relationships between access control rule invocations.

acr-ref <and/> acr-ref
acr-ref <or/> acr-ref
<not/> acr-ref

Authentication Access Control Rule

Requires user authentication and controls access based on the user's role(s). This is commonly referred to as Role-based Access Control (RBAC).

<auth-acr>

An authentication access control rule forces user authentication and controls access by the user's roles. It is composed of zero or more role-constraints, each of which identifies the name of a role that is assigned at authentication time. Each role constraint may also specify a role-class, which is the Java class implementing the role. Access is granted if:

1. the user is authenticated and no role-constraints are required

or if:

1. the user is authenticated
2. and at least one role-constraint that grants access matches a role associated with the authenticated user
3. and no role-constraints that deny access match the authenticated user

A single authentication access control rule enables you to grant and deny access to any number of authenticated users by role name and/or role-class. When a user is authenticated the Cams policy server authentication configured for the protected resource assigns one or more roles to the user (a user is always assigned at least one role with his own user name).

Let's clarify with an example where a user authenticates with a user name of johndoe and password. The following roles are assigned by the Cams policy server authentication system:

1. user: johndoe
2. role: employee
3. role: engineering

Don't let the user designation fool you, johndoe is also a role. Keep in mind that a Cams access control policy can distinguish internall between a user role and a role, when required, using a role-class constraint.

<auth-acr 
  id="access control rule identifier"
  debug="true | false">
  ...
</auth-acr> 

<role-constraint>

A role-constraint grants or denies an authenticated user access by virtue of the identities (roles) associated at login time. A role-constraint applies to an authenticated user if:

1. it contains only a role-name and the user has that role
2. if contains a role-name and a role-class and the user has that role implemented by the specified Java class

A role-constraint grants access if:

1. it applies to the authenticated user
2. the role-constraint implicitly or explicitly has attribute: accessGranted="true"

If a role-constraint applies to the user and denies access, then the authentication access control rule as a whole will immediately deny access. To optimize performance, place any role-constraints that deny access at the beginning of the rule.

<role-constraint accessGranted="true | false">
  ...
</role-constraint> 

<role-name>

Identifies the name of a role that is possibly assigned to an authenticated user.

<role-name>role name</role-name>

<role-class>

Identifies the fully-qualified name of the Java class that implements a role that is possibly assigned to an authenticated user. If specified, the role-constraint applies only if an authenticated user has a role-name implemented by the specified role-class.

To determine the classes assigned to authenticated users, you'll need to know the Login Modules that were used to authenticate the user and the classes they use to add principals (roles). For more information, see the Login Configuration document.

<role-class>fully.qualified.JavaClassName</role-class>

Authentication Method Access Control Rule

An access control rule that requires a particular method of authentication to access a protected resource. The Cams login module implementations are responsible adding an authentication method
to the user session corresponding to one of the following standard authentication methods:

• Password - The authentication was performed by means of a password.
• Cams Autologin - The authentication was performed by means of a Cams autologin.
• Kerberos - The authentication was performed by means of the Kerberos protocol [RFC 1510].
• Secure Remote Password (SRP) - The authentication was performed by means of Secure Remote Password protocol as specified in [RFC 2945].
• Hardware Token - The authentication was performed by means of an unspecified hardware token.
• SSL/TLS Certificate Based Client Authentication - The authentication was performed using either the SSL or TLS protocol with certificate based client authentication.
• X.509 Public Key - The authentication was performed by some (unspecified) mechanism on a key authenticated by means of an X.509 PKI.
• PGP Public Key - The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a PGP web of trust.
• SPKI Public Key - The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a SPKI PKI.
• XKMS Public Key - The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a XKMS trust service.
• XML Digital Signature - The authentication was performed by means of an XML digital signature.

All standard Cams login modules support both the PASSWORD and AUTOLOGIN authentication methods. See the documentation for the login modules supplied with Cams or any custom login module in use at your site for information on the supported authentication methods.

NOTE: A complete description of the non-cams authentication methods can be found in the Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1.

<auth-method-acr>

Implements an access control rule based on the user authentication method. This rule should usually be combined with an access control rule expression such that, minimally, the expression evaluates not only the authentication method but first ensures that the user is authenticated. It might also be combined with an obligation-acr to, on a denied exception, prompt the user for a higher level of authentication. For example, if a user is logged in with the Cams autologin authentication method, an access control rule expression can be implemented with an obligation to redirect the user to a login page, which would prompt for user name and password authentication. An example is provide below.

<auth-method-acr 
  id="access control rule identifier" 
  method="uniform resource name"/>

<!-- Require the PASSWORD authentication method -->
<auth-method-acr 
  id="Require Password Authentication Method"        
  method="urn:oasis:names:tc:SAML:1.0:am:password"/>

Host Access Control Rule

Grant or deny access to a user based on the host from which he's attempting to access a protected resource.

WARNING: It is not always possible to resolve a remote host's name using the Internet's Domain Name Service (DNS). Even if a host name can be resolved, performance is sometimes poor, which can adversely effect performance. We recommend that you use host name patterns only in a controlled environments (like an intranet), where you're likely to have more control over DNS configuration and performance.

<host-acr>

Grants or denies access based on the host name and/or IP address of the user's remote computer. This rule does not require user authentication, but does require that the remote host and/or remote address be known. A host access control rule will evaluate to true ONLY if:

1. it contains no constraints whatsoever (i.e. it's empty)
2. a remote host matches an accept pattern, but does not match a deny pattern

<host-acr 
  id="access control rule identifier"
  debug="true | false">
	...
</host-acr>

<allow-host>

Defines one or more remote host name patterns. If a remote host attempts to access a resource protected by the security constraint associated with this rule and it's host name matches a pattern within this constraint, then that remote host is eligible to have access granted. Access will be granted by the enclosing rule if the host does not match a deny pattern. If the remote host name is not available, then it cannot match this pattern so this constraint does not apply.

<allow-host>
  ...
</allow-host> 

<deny-host>

Defines one or more remote host name patterns. If a remote host attempts to access a resource protected by the security-constraint associated with this rule and it's host name matches a pattern within this constraint, then that remote host is immediately denied access. If the remote host name is not available, then it cannot match this pattern so this constraint does not apply.

<deny-host>
  ...
</deny-host> 

<host>

The pattern for a remote host name with support for regular expression matching. See the Regular Expressions document for more information on regular expression pattern matching.

<host>host name or host pattern</host>

<allow-address>

Defines one or more remote host IP address patterns. If a remote host attempts to access a resource protected by the security constraint associated with this rule and it's host IP address matches a pattern within this constraint, then that remote host is eligible to have access granted. Access will be granted by the enclosing rule only if the host does not match a deny pattern. If the remote host IP address is not available, then it cannot match this pattern so this constraint does not apply.

<allow-address>
  ...
</allow-address> 

<deny-address>

Defines one or more remote host IP address patterns. If a remote host attempts to access a resource protected by the security constraint associated with this rule and it's host IP address matches a pattern within this constraint, then that remote host is immediately denied access. If the remote host name is not available, then it cannot match this pattern so this constraint does not apply.

<deny-address>
  ...
</deny-address> 

<address>

The pattern for a remote host IP address with support for regular expression matching. Zero or more are required. See the Regular Expressions document for more information on pattern matching.

<address>host IP address or host IP address pattern</address>

Attribute Access Control Rule

Enables evaluation of HTTP and other access control request attributes using if-then-else style access control logic. If a given access control request matches a set of conditions, then another referenced access control rule associated with those conditions is evaluated to determine if access is granted or denied.

<attr-acr>

Each attribute access control rule may contain zero or more targets. A target has a nested access control rule reference that is evaluated if it is the first target where ALL associated attribute conditions match an access control request. If the attribute access control rule does not contain any targets or an access control request does not match any targets, then a default access control rule is evaluated.

The following pseudo code expresses an example of business logic that can be implemented by attribute access control rule:

   if ((requested an historical report) AND
       (requested report-type is FINANCIAL or AUDIT) AND
       (requested year is 2002 or 2003)) then

      if (user is authenticated) then
         if (user has the Shareholder role) then
            Grant Access;
         else
            Deny Access;
      else
         Deny Access, Require User Authentication;
   else
      Deny Access, No match - Target missing required attribute;

Nearly every value within an access control request can be referenced as an attribute. Each attribute within an access control request has an identifier, belongs to a category, and has one or more attribute values of a specific data type.

Every standard Cams attribute identifier, category and data type is designated by a Uniform Resource Name (URN). For example:

• Attribute identifier: urn:cams:1.0:names:resource:resource-id
• Category: urn:cams:1.0:names:attribute-category:resource
• Data type: urn:cams:1.0:names:data-type:string

NOTE: A URN is a sub-category of Uniform Resource Identifer (URI), which names a resource but does not specify how to locate it. A more detailed explanation of URNs, URIs, and URLs is available in the Java 2 Javadoc for class java.net.URI, which is used internally by Cams to store URNs.

Use of URNs for Cams attribute identifiers, categories and data types provides a highly structured and extensible naming strategy. See the following sections for more details:

• Standard Cams Attribute Categories
• Standard Cams Data Types
• Standard Cams Attribute Identifiers

<attr-acr 
  id="access control rule identifier" 
  default-acr-ref="access control rule indentifier reference"
  debug="true|false">
  ...
</attr-acr> 

<!--  
   If the ReportBuilder application is accessed, make sure the required HTTP  
   parameters are present and valid. If the target matches, then invoke the 
   "shareholder rule", access control rule, which will enforce authentication 
   and the shareholder role. -->

<auth-acr id="shareholder rule">
  <role-constraint>
    <role-name>shareholder</role-name>
  </role-constraint>
</auth-acr>

<attr-acr id="shareholder reportbuilder rule" default-acr-ref="denied">

  <!-- Target 1: Protect FINANCIAL and AUDIT reports for years 2002-2003 -->
  <attr-target desc="FINANCIAL and AUDIT reports for years 2002-2003">
    <acr-ref id="shareholder rule"/>

    <!-- Conditions for resource attributes -->
    <attr-conditions 
      category="urn:cams:1.0:names:attribute-category:resource">

      <!-- Match the URI where historical reports are requested -->
      <attr-condition 
         desc="Historical report resource ID (URI) Condition">

         <attr-match 
           function-id="urn:cams:1.0:names:function:regexp-string-match"
           desc="Match the URI for accessing historical reports">
           <attr-designator
             data-type="urn:cams:1.0:names:data-type:string" 
             id="urn:cams:1.0:names:resource:resource-id"
             must-be-present="true"/>
           <attr-value
             data-type="urn:cams:1.0:names:data-type:string">
             ^.*/gethistorical.do
           </attr-value>
         </attr-match> 

      </attr-condition>

    </attr-conditions>

    <!-- Conditions for "http-param" attributes -->
    <attr-conditions 
      category="urn:cams:1.0:names:attribute-category:action">

      <!-- Require valid report-type -->
      <attr-condition 
        desc="Required the report-type parameter to be FINANCIAL or AUDIT">

        <attr-match 
          function-id="urn:cams:1.0:names:function:equals-ignorecase-string-match"
          desc="Match the FINANCIAL report type">
          <attr-designator 
            data-type="urn:cams:1.0:names:data-type:string" 
            id="urn:cams:1.0:names:action:http-param:report-type"
            must-be-present="true"/>
          <attr-value 
            data-type="urn:cams:1.0:names:data-type:string">
            FINANCIAL
          </attr-value>
        </attr-match> 

        <attr-match 
          function-id="urn:cams:1.0:names:function:equals-ignorecase-string-match"
          desc="Match the AUDIT report type">
          <attr-designator
            data-type="urn:cams:1.0:names:data-type:string" 
            id="urn:cams:1.0:names:action:http-param:report-type"
            must-be-present="true"/>
          <attr-value 
            data-type="urn:cams:1.0:names:data-type:string">
            AUDIT
          </attr-value>
        </attr-match> 
      </attr-condition>

      <!-- Require valid year -->
      <attr-condition 
        desc="Require the year parameter to be 2003 or 2005">

        <attr-match
          function-id="urn:cams:1.0:names:function:regexp-string-match"
          desc="Match the FINANCIAL report type">
          <attr-designator
            data-type="urn:cams:1.0:names:data-type:string" 
            id="urn:cams:1.0:names:action:http-param:year"
            must-be-present="true"/>
          <attr-value 
            data-type="urn:cams:1.0:names:data-type:string">
            200[3-4]
          </attr-value>
        </attr-match>

      </attr-condition>

    </attr-conditions>

  </attr-target>

</attr-acr>

<attr-target>

Creates a possible target for an access control request within an attribute access control rule. An attribute target contains one access control rule reference and any number of attribute conditions, which are evaluated in order to determine if the target applies. If ALL attribute conditions associated with a target are met, then the access control rule referenced by the target is evaluated and its response is returned as the enclosing attribute rule response.

<attr-target desc="textual description"> 
 ...
</attr-target> 

<attr-conditions>

Creates an attribute category-specific set of conditions for matching an enclosing attribute target. Attribute conditions contains one or more individual attribute condition elements, which are evaluated in order. If ALL individual attribute condition elements match, then the overall attribute conditions for the given category match. A sequence of conditions, all of which must be met in order to match the enclosing attribute target. One attr-conditions element is required for each category of attributes.

<attr-conditions 
  category="attribute category URI"
  desc="textual description"> 
  ...
</attr-conditions> 

<attr-condition>

Creates an individual attribute condition evaluated against an access control request. Each attribute condition contains one or more attribute match operations. If ANY enclosed attribute match succeeds, then the condition succeeds. If ALL enclosed attribute matches fail, then the condition fails. An individual condition within a set of category-specific attribute conditions. If all attr-condition elements match a given access control request, then the enclosing attr-conditions matches.

<attr-condition desc="textual description"> 
  ...
</attr-condition> 

<attr-match>

Creates an attribute match, which is reponsible for matching an attribute value from an access control request against a value or pattern of values. An attribute match specifies a function to be used, an attribute designator (which identifies which attribute to compare), and an attribute value which indicates the value or pattern of values to match. An individual attribute match operation. An attri-condition may contain any number of attr-match elements. If ANY attr-match succeeds, then the attr-condition succeeds, else the attr-condition fails, the enclosing attr-conditions fail, and the enclosing attr-target does not match the access control request.

<attr-match
  function-id="matching function URI" 
  desc="textual description"> 
  ...
</attr-match> 

<attr-designator>

An attribute designator selects values from an access control request by attribute identifier, data type, and category (indicated by the enclosing attr-conditions). The values (if they exist) can then be used by the enclosing attribute matching function to compare against an attribute value or pattern of attribute values.

Attribute designators are also responsible for indicating whether or not a given attribute must be present in an access control request in order to evaluate the enclosing condition. If a designator indicates that a given attribute must be present, but it is not available from the access control request, then the enclosing attribute access control rule denies access due to missing/required attribute. If a designator indicates that a given attribute need not be present and it is not available from the access control request, then the enclosing attribute match is ignored. If a subsequent attribute match within the same condition matches, then the condition matches and evaluat