Back | Next | Contents Cams Administrator's Guide

Access Control Services

This document details how Cams access control services work and how to configure an access control policy, which is found in the access-control-policy.xml file of each security domain. See the Access Control Policy Tag Reference for reference information on how to configure all supplied access control rules.

Access Control Conceptual Model

The Cams access control model defines two major responsibilities:

  • Policy Enforcement Point - A location in the system where a security policy is enforced. For Cams, this is usually a Cams web agent installed in a web server like Apache, IIS or Tomcat.
  • Policy Decision Point - A location in the system where the access control decisions are made. For Cams, this is always the Cams policy server.

To implement access control on a client's request, the policy enforcement point asks the policy decision point whether to grant or deny access to a resource. If the policy decision point grants access, then the policy enforcement point allows access to the resource. If the policy decision point denies access, then the policy enforcement point does not allow access to the resource.

Figure 2 - Cams access control model

Figure 2 shows a deployment where web pages, web applications and other URL resources are accessible via a web server. The policy enforcement point is a Cams web agent installed in the web server and the policy decision point is the Cams policy server. Using a web browser, a user requests access to an HTTP URL from a web server, where a Cams web agent intercepts the request and asks the Cams policy server if access is granted or denied. The Cams policy server decides to grant or deny access by matching the resource request to the evaluation of a linked access control rule in a security policy, sometimes after first authenticating a user. The Cams web agent enforces the resulting decision sometimes caching the decision to increase performance on subsequent requests.

Cams Security Domains

Cams partitions access control, authentication and session management responsibilities into security domains. Security domains enable a separation of administrative responsibilities based on organizational boundaries. Each security domain has an access control service that uses an access control policy that contains permissions for accessing protected resources. Each permission:

  • is associated with a type of resource that it protects (e.g. http or cams)
  • contains a pattern for matching resource identifier(s) (e.g. http://www.cafesoft.com:80/secure*)
  • may specify one or more actions (e.g. GET, POST, PUT, etc.)
  • references an access control rule that protects access to matching resources or a security domain to which access control will be delegated (e.g. "acr-ref id=granted")

Permissions are organized into separate permission collections (based on type) and access control rules are stored in an access control rule library, which enables them to be reused, managed and referenced from permissions and other access control rules. Figure 2 shows the relationships between these major access control components.

Figure 2 - Relationships between major Cams access control components

How Cams Access Control Works

When a Cams web agent needs to check access to a resource, it submits a resource request to a Cams policy server. The Cams policy server gives the request to the access control service within the system security domain, which either handles it or delegates the request to another security domain as configured in it's access control policy. So, in order for a resource to be protected by Cams, a permission that matches its identifier and action must be configured in the Cams system security domain.

Access control decisions are based on a resource request, which is sent from a Cams web agent as part of an access control check request. Each resource request includes a resource type, a unique resource identifier and one or more requested actions. For example, an attempt to access a web page via a web browser might correspond to the following Cams resource request parameters:

  1. Resource type: http
  2. Resource id: http://www.cafesoft.com:80/index.html
  3. Action: GET

The enclosing access control check request contains other parameters that may be important for deciding whether to grant or deny access including:

  • the identity of a user (if the user is authenticated)
  • the remote host on which the user is operating
  • the confidentiality of the network connection by which a resource might be accessed
  • the type(s) of authentication successfully passed by the user
  • the date/time of the request
  • any HTTP query parameters optionally sent with a request
  • Cams web agent attributes optionally sent with a request
  • the fulfillment of an SQL query

When the Cams high-level access control service receives this request, the following actions are taken:

  1. A Cams web agent, usually installed at a resource provider, will connect with the Cams policy server and send an access control request (hereafter referred to as the request).
  2. The request and its enclosed resource request are given to the Cams access control service.
  3. The access control service gives the request to the system security domain's access control service
  4. The system security domain's access control service passes the request to it's access control pipeline, which contains a series of access control valves
  5. Each access control valve can ignore the request, partially handle the request or completely handle the request.
  6. By default, an access control valve will log the request
  7. By default, a Cams basic access control valve will invoke the security domain's access control policy
  8. The access control policy will find the permission collection that matches the resource type
  9. The permission collection will find the permission that best matches the resource request. The rules for best match can depend on the resource type and is explained in detail below.
  10. If the permission references an access control rule, that rule will be invoked on the request. If the permission references another security domain, the request will be forwarded to that security domain.
  11. The invoked access control rule will evaluate the request, possibly invoking other nested access control rules. An access control response will be populated and returned to the Cams web agent.

This entire processing pipeline is memory-resident, so it's very fast. The design enables pluggable support for new resource types, new access control rule types and pluggable access control valves. The Cams policy server engine is thread-safe and can be used stand-alone (as supplied) or embedded within applications.

In order for a permission to match a specific resource request, the following criteria must be met:

  • the id of the requested resource must match the permission's resource pattern
  • the action on the requested resource must match one or more of the permission's actions

To understand permission matching rules, consider the access control policy in Example 1.

ID Resource Type Resource Pattern Action(s)
1 http http://www.foo.com:80/secure/* GET, POST
2 http http://www.foo.com:80/secure/employee/* GET, POST
3 http http://www.foo.com:80/secure/employee/* PUT, DELETE
4 http http://www.foo.com:80/secure/employee/* POST

Example 1 - Example permissions within an access control policy

Each row represents a permission to access some HTTP (web) resources.

  • for request: GET http://www.foo.com/secure/index.html, only permission 1 matches.
  • for request: POST http://www.foo.com/secure/employee/suggestion, permissions 1 and 2 match the request, but 2 is more specific so it takes precedence. In this case more specific means that permission 1's resource pattern is longer than permission 2's resource pattern. The request does not match permission 3 because the requested POST action is not associated with permission 3.
  • for request: DELETE http://www.foo.com/secure/employee/picnic_2002.html, only permission 3 matches because it's the only one that matches the resource pattern and the DELETE action.

Permission 4 is incompatible with permission 2 because both have identical resource patterns and a matching action. Cams requires unambiguous rules for assigning access control responsibility within a security domain, so it will not allow insertion of a permission that overlaps another permission. Permissions are considered overlapping if they have the same type, have identical resource patterns and have at least one action in common. Without this precaution, Cams would not be able to decide which of the two permissions has responsibility for protecting a matching resource request. If an access control policy contains an overlapping permission during access control policy loading, it will fail to load.

Finally, if the access controller does not find a matching permission, then access will be either granted or denied based on the default bias you set for the access control policy.

Managing a Cams Access Control Policy

Cams stores each security domain's access control policy in an XML file named access-control-policy.xml, which is loaded when the Cams policy server is started. An access control policy is configured by editing this file and automatically reloaded by the access control policy monitor service if modified at runtime. The following procedure is recommended for managing configuration changes to an access-control-policy.xml file.

NOTE: We strongly recommended that you test all configuration changes to an access control policy in a development or staging environment before you deploy to a production environment.

Step 1 - Make a backup copy of access-control-policy.xml

Copy the existing access-control-policy.xml file to a file named:

access-control-policy.xml.<lastModifiedTime>

The value for lastModifiedTime is the value of the attribute shown in the first XML element of Example 2. For example: access-control-policy.xml.200701011200. This provides a way to roll back to a known access control policy if the changes you make will not load or don't behave as desired.

Step 2 - Edit and save access-control-policy.xml

Edit the access-control-policy.xml file as described in Configuring a Cams Access Control Policy. If the Cams policy server is already running, you must increase the value of lastModifiedTime using the date/time format YYYYMMDDHHmm or automatic reloading will fail. The lastModifiedTime value ensures that all Cams policy servers in a cluster use the same access control policy. It is also important for Cams web agents, which are required to clear cached access control responses when an access control policy is modified.

Step 3 - Start the Cams policy server or reload access-control-policy.xml

If the Cams policy server is not running, start it. The security domain's access control service attempts to load the access-control-policy.xml file on startup. If the access control policy has an error, it is reported to the security domain's trace log and the security domain will fail to load. If the security domain is the required system security domain, the Cams policy server will not start.

If the Cams policy server is already running and automatic access control policy reloading is enabled, the access control service will attempt to reload access-control-policy.xml only when the file date/time changes. If the access-control-policy.xml lastModifiedTime date/time has not been increased relative to the currently loaded access control policy or a validation error occurs, then the reload will fail and the existing access control policy will stay in effect. You can confirm that the access control policy is loaded or reloaded by looking in the security domain trace log file, which displays the lastModifiedTime date/time associated with a newly loaded access-control-policy.xml file.

Step 4 - If necessary, roll back to a previous access control policy

To help Cams web agents efficiently cache access control responses and to avoid access control policy reloading failures due to an invalid lastModifiedTime date/time, use the following file management procedure to roll back to a previous access control policy. For purposes of these instructions, let's assume that the access control policy that we'd like to roll back to is in file: access-control-policy.xml.200701111200.

  1. Copy the access-control-policy.xml file saved in Step 1 above to a new file with the current lastModifiedTime date/time stamp. For example, if the current date/time is Jan 1, 2007 12:30 PM, copy:

    access-control-policy.xml.200503231200
    to access-control-policy.xml.200701111230

  2. Edit and save access-control-policy.xml.200503231230 with the lastModifiedTime value set to:

    200701111230.

  3. Copy:

    access-control-policy.xml.200701211230 to access-control-policy.xml

Configuring a Cams Access Control Policy

This section uses an example Cams access-control-policy.xml file to describe how you configure Cams permissions and access control rules. Example 2 shows how an access control policy might be configured to protect some HTTP resources available from a fictitious application server at http://www.acme.com that hosts web resources available to:

  • everybody
  • only authenticated employees
  • only authenticated managers on the local area network

Each of these access control requirements can be expressed as a distinct permission within the access control policy's <permission collection> start and end tags. Access control rules are defined in the access control rules library within the <acr-lib> start and end tags. Please refer to the comments in Example 2 to understand more about each permission and follow its associated access control rule reference (e.g. <acr-ref id="ACME Employee Rule"/>) to the access control rule library below.

<!-- Declare an access control policy -->
<access-control-policy defaultBias="denied" lastModifiedTime="200701011200">

    <!-- HTTP (Web) resource permissions -->
    <permission-collection type="http" desc="HTTP (Web) Resources">

       <!-- Declare resources available to the public (Cams intrinsic rules
like "granted" do not require definition in <acr-lib>) -->
<permission desc="ACME Public Web Resources" actions="GET"> <resource-pattern id="*://*:*/*" ignoreCase="false"/>
<acr-ref id="granted"/>
</permission> <!-- Declare resources available to only ACME employees --> <permission desc="ACME Employee Web Resources" actions="GET,POST"> <resource-pattern id="*://*:*/employee*" ignoreCase="false"/> <acr-ref id="ACME Employee Rule"/>
</permission> <!-- Declare resources available to only ACME manager users --> <permission desc="ACME Manager Web Resources"> <resource-pattern id="*://*:*/manager*" ignoreCase="false"/>
<acr-ref id="ACME Manager LAN-Auth-Conf Rule"/>
</permission>
</permission-collection> <!-- Access Control Rule Library --> <acr-lib> <!-- Require an authenticated user to have the "employee" role. --> <auth-acr id="ACME Employee Rule"> <role-constraint> <role-name>employee</role-name> </role-constraint> </auth-acr> <!-- Require hosts to be on the ACME Local Area Network. --> <host-acr id="ACME LAN Rule">
<allow-address>
<address>192.168.0.*</address>
</allow-address> </host-acr> <!-- Require an authenticated user to have the "manager" role that is implemented by a particular role class. --> <auth-acr id="ACME Manager Auth Rule"> <role-constraint> <role-name>manager</role-name> <role-class>com.cafesoft.cams.auth.CSRolePrincipal</role-class> </role-constraint> </auth-acr> <!-- Require: 1. the host to be on the ACME Local Area Network 2. the user to be authenticated with the "manager" role 3. a confidential (SSL/TLS) connection for privacy --> <acr id="ACME Manager LAN-Auth-Conf Rule"> <acr-ref id="ACME LAN Rule"> <and/> <acr-ref id="ACME Manager Auth Rule"> <and/> <confidential/> </acr> </acr-lib> </access-control-policy>

Example 2 - An example Cams access control policy defined in access-control-policy.xml

NOTE: By default, the Cams access-control-policy.xml file defaultBias is set to grant access. Normally, security best practice is to fail safe and deny access by default. In practice, most web resources are public and should be unconditionally granted access with access restricted to only specified resources. If most resources on your site need to be protected, you'll want to set the defaultBias to denied. Otherwise, setting the defaultBias to granted is generally more practical.

Configuring Permissions

Each Cams permission protects a specific type of resource and is enclosed within a permission collection specific for that type. For example, the system security domain's access control policy defines two permission collections: one for HTTP permissions (http) and one for Cams system-level permissions (cams). Although http and cams resources are both identified using a URL syntax, they are different resource types and therefore protected by permissions in different permission collections.

A Cams permission specifies the following elements:

  1. A textual description helpful for administrators and debugging
  2. An optional list of actions used to match one or more resources to be protected
  3. A resource pattern formulated to match the fully-qualified identifier of one or more resources to be protected
  4. A reference to an access control rule used to protect matching resources or a reference to another security domain to which the access control check will be delegated

The following sections provide more details on each of these elements.

Setting a Permission's Description

The textual description for a permission is useful for administration and debugging. Enter a unique value that describes the resources protected by the permission, as shown in Example 3.

<!-- Declare resources available to only ACME employees -->
<permission desc="ACME Employee Web Resources" actions="GET,POST">
 <resource-pattern id="*://*:*/employee*" ignoreCase="false"/>
 <acr-ref id="ACME Employee Rule"/>
</permission>

Example 3 - Setting a permission's description in access-control-policy.xml

Setting a Permission's Actions

A permission's actions are used when selecting which permission will apply to an access control request. An access control request specifies zero or more actions and a resource identifier. If all of the actions specified by the access control request match actions specified by a permission, then that permission is a candidate for handling the request. Example 4 shows how a permission's actions may be set in access-control-policy.xml.

<!-- Declare resources available to only ACME employees -->
<permission desc="ACME Employee Web Resources" actions="GET,POST">
 <resource-pattern id="*://*:*/employee*" ignoreCase="false"/>
 <acr-ref id="ACME Employee Rule"/>
</permission>

Example 4 - Setting a permission's actions in access-control-policy.xml

NOTE: The permission's resource pattern must also match the access control request's resource identifier to remain a candidate.

Example 5 shows how the actions specified within an access control request match actions defined for hypothetical http permissions.

Case # Access Control Request Action(s) Permission Action(s) Match
1
GET, POST
GET, POST
Yes
2
GET
GET, POST
Yes
3
POST
GET
No
4
GET
(None specified)
Yes
5
POST, GET
GET, PUT, POST
Yes
6
GET
POST, PUT, get (error)
No

Example 5 - Matching access control request actions against permission actions

Cases 2 and 5 shows that only a subset of a permission's actions must match the access control request's actions. Case 4 shows that when no actions are specified for a permission, then all actions are implied. Case 5 shows that the order of actions is not significant. Case 6 shows that actions are case-sensitive. In fact, the access control policy containing this invalid action would fail to load and an exception would be reported in the enclosing security domain's trace log.

Finally, if the access controller matches a resource but does not find a matching action, then access will be either granted or denied based on the default bias you set for the access control policy.

NOTE: HTTP actions can only be GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK or DEBUG. When HTTP requests with unrecognized actions are sent to a web server with a Cams web agent, a 5102 web agent error will result.

Configuring Resource Patterns

A permission's resource pattern is used to match the resource identifier specified within an access control request. The recommended practice is to make a 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. Example 6 shows how a permission's resource pattern may be set.

<!-- Declare web pages available to only ACME employees -->
<permission desc="ACME Employee Web Resources" actions="GET,POST">
 <resource-pattern id="*://*:*/employee*" ignoreCase="false"/>
 <acr-ref id="ACME Employee Rule"/>
</permission>

Example 6 - Setting a permission's resource pattern in access-control-policy.xml

WARNING: Some web servers and their underlying operating systems (most notably IIS on Windows) provide case-insensitive access to resources. Because Cams access control policy evaluations are case sensitive by default, it is easy to create an access control policy security hole on case-insensitive servers. To prevent this, a resource-pattern XML element ignoreCase="true|false" is available. If not specified, the default behavior is false, resulting in case-sensitive URI pattern matching. Usually, this element should be supplied and set to true for IIS and left out for other web servers.

Example Resource Patterns

Example 7 shows some sample resource patterns for Cams http resource types. For purposes of matching, these URL-based resource patterns are divided by Cams into four distinct fields:

shemePattern :// hostPattern : portPattern / uriPattern

where:

  • scheme - resource type, currently either http or cams
  • host - IP address or DNS host name for the server where the resource is located
  • port - the porter number of the server for the resource
  • URI - the path on the server to the resource

Each field within the overall resource pattern may be customized independently to make it as specific or as general as needed.

Resource Type Resource Pattern Description
http *://*:*/* Match any http or https URL on any host, any port, and with any URI.
http http://*:*/* Match any http URL on any host, on any port, and with any URI.
http http://www.foo.com:*/* Match any http URL on host www.foo.com, on any port, and with any URI.
http http://www.foo.com:80/* Match any http URL on host www.foo.com, on port 80, an with any URI.
http http://www.foo.com:80/index.html Match the unique URL with scheme=http, host=www.foo.com, on port=80, and URI=index.html.
http *://*:*/*.jsp Match any http or https URL on any host, any port, and with any URI that ends with ".jsp".
http *://*:*/images/*.gif Match any http or https URL on any host, any port, and with any URI that starts with "/images" and ends with ".gif".
http https://*:*/secure/* Match any https URL on any host, any port, and with a URI that starts with "/secure/".
http *://*.foo.com:*/* Match any http or https URL on any host whose name ends with ".foo.com", on any port, and with any URI.
http *://www.*:*/* Match any http or https URL on any host whose name starts with "www.", on any port, and with any URI.
http *://*.foo.*:*/* Match any http or https URL on any host whose name contains ".foo.", On any port, and with any URI.

Example 7 - Sample Resource Patterns for http and cams resource types

For HTTP URL-based resource patterns, 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.

Legal and Illegal URL-based Resource Patterns

URL-based resource patterns include 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. In addition, the meaning of a wildcard depends on where it is used. Cams URL-based resource patterns have the following general form:

shemePattern :// hostPattern : portPattern / uriPattern

The overall resource pattern is composed of four sub-patterns, each of which has its own validation rules. Example 8 summarizes the legal and illegal URL-based resource patterns for the Cams http resource type.

Sub-Pattern Type

Example Sub-Patterns Description
schemePattern
  • *
  • http
  • https
Valid scheme pattern values are: *, http, or https. If the pattern is *, then it will match http resource requests with schemes: http or https. Scheme pattern matching is case-insensitive.
hostPattern
  • *
  • www.foo.com
  • *.foo.com
  • www.foo.*
  • *.foo.*
  • *foo*
  • 192.168.1.1
  • 192.168.*
  • *.168.1.1
  • *.168.*

Valid host pattern values include the wildcard character (matches any host or IP address), a literal host name or IP address (matching is case-insensitive) with a wildcard character at the beginning, end, or beginning and end of the pattern. Host pattern matching is case-insensitive.

NOTE: Host patterns may not contain an embedded wildcard character. In other words, the wildcard character is allowed only at the beginning and/or end of the pattern.

portPattern
  • *
  • 80
  • 443
  • 8080
Valid port patterns include: * (matches any integer from 1-32767) or a literal integer value. Case does not apply.
uriPattern
  • /index.html
  • /images/*
  • /*.jsp
  • /products/*.asp

All URI patterns must start with a slash and may have any of the following forms:

  • /a (literal)
  • /a* (starts with /a)
  • /a*b (starts with /a and ends with b

URI pattern matching is case-sensitive unless the resource-pattern ignoreCase attribute is set to true.

NOTE: URI patterns of the form: /a*b* are not supported. For example: /*/index.*ml will report a resource pattern error.

Example 8 - URL resource pattern examples for Cams http resources

NOTE: Most web servers resolve multiple juxtaposed slashes in a URI to a single slash. For example:

http://www.mycompany.com/mysecure//resource.html

would resolve to:

http://www.mycompany.com/mysecure/resource.html

Because Cams does resource pattern matching on a character by character basis, this situation creates a potential access control policy security hole. To prevent this, Cams reduces two or more juxtaposed slashes in the URI to one (this does not apply to the expected double slash between the scheme and the host).

NOTE: You should usually try to keep the scheme, host and port as general as possible (e.g. *://*:*). This facilitates moving access-control-policy.xml between development, staging and production systems. Explicit scheme, host and port values are useful when HTTP and HTTPS resources need different access control rules, or you have different web servers with similar resources that have distinct security requirements.

Linking a Permission to an Access Control Rule

Example 9 shows how the access control rule associated with a permission may be set in access-control-policy.xml. The identified access control rule instance must be a Cams intrinsic access control rule (like granted, denied or confidential) or defined within the same access-control-policy.xml in the access control rule library.

<!-- Declare web pages available to only ACME employees -->
<permission desc="ACME Employee Web Resources" actions="GET,POST">
 <resource-pattern id="http://www.acme.com:80/employee*" ignoreCase="false"/>
 <acr-ref id="ACME Employee Rule"/>
</permission>

Example 9 - Setting the access control rule for a permission in access-control-policy.xml

Delegating a Permission to another Security Domain

Example 10 shows how a permission can delegate to another security domain. The destination security domain becomes the owner of the resources matching the associated resource pattern. It is up to the access control policy in the destination security domain to define permissions as required to protect the associated resources.

NOTE: The system security domain's access control policy receives EVERY access control request. In order for any other security domain to handle an access control requests, the system security domain's access control policy must delegate to it.

<!-- Delegate http permissions for "www.foo.com" -->
<permission desc="Delegate web permissions for www.foo.com">
 <resource-pattern id="*://www.foo.com:*/*" ignoreCase="false"/>
 <owner id="mydomain"/>
</permission>

Example 10 - Delegating a ownership of a resource to another security domain in access-control-policy.xml

Debugging Permissions

Permissions may be debugged by setting a debug flag and viewing the contents of the security domain-specific trace log. For example, if a permission is contained within the access control policy of the mydomain security domain, its trace log (by default), is in file CAMS_HOME/logs/mydomain-trace.log.

Example 11 shows how the debug flag can be enabled for a permission. You may also want to enable the debug flag on element <access-control-policy debug="true">, <permission-collection debug="true"> and possibly at the access control rule level too.

<!-- Declare web pages available to only ACME employees -->
<permission desc="ACME Employee Web Resources" actions="GET,POST" debug="true">
 <resource-pattern id="http://www.acme.com:80/employee*" ignoreCase="false"/>
 <acr-ref id="ACME Employee Rule"/>
</permission>

Example 11 - Enabling debug on a permission in access-control-policy.xml

Configuring Access Control Rules

After any and all security domain delegations are performed, an access control rule is evaluated to determine if an access control check request will be granted or denied. The following Cams access control rules, called intrinsic rules, are always present in all security domains and require no further definition:

  • granted -always grant access unconditionally
  • denied - always deny access unconditionally
  • confidential - grant access only if the connection is confidential (e.g. HTTPS)

Most access control rules are defined for your site-specific security policy requirements. You do this within the access control rule library using the syntax defined for each access control rule. For example, if you want to create a role-based access control rule that requires a user to have the employee role, you would define a rule similar to the one in Example 12.

<!-- Require an authenticated user to have the "employee" role. -->
<auth-acr id="ACME Employee Rule">
 <role-constraint>
  <role-name>employee</role-name>
 </role-constraint>
</auth-acr>

Example 12 - Defining a role-based access control rule

One and only one access control rule library XML block is defined in each security domain's access-control-policy.xml file (immediately following all permission collections). Each access control rule must have a unique identifier, which is used for reference by permissions and other access control rules. You can also nest access control rules within some access control rules and can combine all access control rules using AND, OR and NOT operators to create new access control rules. Example 13 shows how.

<!-- Require hosts to be on the ACME Local Area Network. -->
<host-acr id="ACME LAN Rule"> 
<allow-address>
<address>192.168.0.*</Address>
</allow-address> </host-acr> <!-- Require an authenticated user to have the "manager" role that is implemented by a particular role class. --> <auth-acr id="ACME Manager Auth Rule"> <role-constraint> <role-name>manager</role-name> <role-class>com.cafesoft.cams.auth.CSRolePrincipal</role-class> </role-constraint> </auth-acr> <!-- Require: 1. the host to be on the ACME Local Area Network 2. the user to be authenticated with the "manager" role 3. a confidential (SSL/TLS) connection for privacy --> <acr id="ACME Manager LAN-Auth-Conf Rule"> <acr-ref id="ACME LAN Rule"> <and/> <acr-ref id="ACME Manager Auth Rule"> <and/> <confidential/> </acr>

Example 13 - Defining a composite access control rule

The composite "ACME Manager LAN-Auth-Conf Rule" is created by using the AND condition between two previously defined rule and the Cams confidential intrinsic rule. Notice that the access control rules referenced by "ACME Manager LAN-Auth-Conf Rule" are defined first in the file, which is required.

In addition to referencing Cams intrinsic rules, you can define the following access control rules within an access control rule library for reference by permissions:

  • Authentication Access Control Rules - Requires user authentication and controls access based on user roles (e.g. Role-based Access Control, or RBAC).
  • Authentication Method Access Control Rule - Requires a particular method of authentication to access a resource such as password or X.509 digital certificate.
  • Host Access Control Rule - Grant or deny access to a user based on the host name or IP address from which access is requested.
  • Attribute Access Control Rule - Enables evaluation of most HTTP and Cams access control request attributes using if-then-else style logic.
  • Obligations Access Control Rule - Associates possible Cams web agent obligations with an access control policy evaluation, such as sending an HTTP redirect to the client's browser.
  • SQL Data Access Control Rule - Ensures the existence or completeness of user-specific SQL database table values.

The syntax for the Cams access control rules you can use in a security domain's access control rule library is quite varied and documented in the Access Control Policy Tag Reference. Also, if the standard Cams access control rules are not sufficient for your site, programmers can implement custom access control rules that can be plugged into the Cams policy server as documented in the Cams Programmers Guide - Cams Access Control Rules.

Back | Next | Contents