7/10

4 Managing Domain Access Controls

This chapter describes how Domain Access Control Lists (ACLs) control calendar operations that span multiple domains. Oracle Communications Calendar Server combines domain ACLs with the calendar and scheduling ACLs to grant or deny levels of access to these operations. All operations within a single domain rely strictly on the calendar and scheduling ACLs.

Topics:

• Domain ACLs Overview

• Authenticated Access

• Authenticated Access Examples

• Anonymous Access Overview

Domain ACLs Overview

In Calendar Server, domain ACLs act as a gateway from one domain to another. When a user in one domain attempts to access a calendar in another domain, Calendar Server first checks the target domain's ACL. If that ACL allows access to the target domain then Calendar Server checks the calendar ACL. The domain ACL itself can also restrict access to the target calendar. For example, if the domain ACL only allows "read" access but the calendar ACL allows "write" access, the request is limited to "read" only.

Calendar Server domain ACLs are in the same form as WCAP calendar and scheduling ACLs. They consist of one or more Access Control Entries (ACEs) separated by semi-colons. The ACE is made up of a "who" part and a "privilege level" part in the form of who:privilege. A "who" can be a domain name in the form of @domain or @ to designate the privilege level for all. The privilege level consists of a single letter.

In general, a domain-level ACL and a user-level ACL behave the same, as they both perform implicit denies and give precedence to more specific ACLs. The only difference occurs when the value is blank. If the domain-level ACL is blank, the server is allowed to continue its check of the user-level ACL. If the user-level ACL is blank, access is explicitly denied.

Authenticated Access

The two LDAP attributes used with domain ACLs are icsDomainNames and icsDomainAcl. Each domain can have zero or more icsDomainNames, which indicate the other domains that are known to this domain. The icsDomainAcl attribute, if it exists, contains the ACL for the domain.

icsDomainNames Attribute Overview

Each icsDomainNames attribute consists of the name of a domain, such example.com. This attribute indicates what other domains a particular domain is aware of. It is used for search operations across domains.

The search operation gets a list of target domains from the icsDomainNames attribute of the requester's domain. The operation first searches the requester's own domain then the domains in the list. As each domain in the list of target domains is processed, the icsDomainAcl of each domain and each calendar's ACL is checked, as described in the next section.

For a search in each of the domains specified in icsDomainNames to succeed, the corresponding domain nodes should have the correct LDAP ACIs and icsDomainAcl setting allowing search from this domain. See the topic on adding LDAP access control in Calendar Server Installation and Configuration Guide for more information on setting LDAP ACIs for domains. See the next section for more information on icsDomainAcl settings.

icsDomainAcl Attribute Overview

If the target domain does not have an icsDomainAcl attribute, the operation continues and the following checks are done by using the calendar and scheduling ACL to see if the operation can be completed.

1. If the icsDomainAcl attribute exists, the ACL is checked for the requesting user's domain. If the ACL has an ACE that contains the requesting user's domain, the privileges given to that domain in the ACE are returned and used to restrict what is available from the calendar and scheduling privileges. If the ACL contains both the domain ACE and the @ ACE, the domain ACE is always used.

2. If the icsDomainAcl attribute exists and does not contain an ACE for the requesting user's domain but it does contain the @ ACE, the privilege level of the @ ACE is used.

3. If the icsDomainAcl attribute exists but does not contain an ACE for the requesting user's domain and also does not contain the @ ACE, access is denied for that user.

Table 4-1 provides more detail on icsDomainAcl conditions and results. The Domain Privileges Returned column describes the rights that are available at the domain level and how these are used to restrict the rights allowed at the calendar and scheduling level.

Table 4-1 icsDomainAcl Conditions and Results

1.	icsDomainAcl	Domain in ACL	Privilege Level Versus Requested Level	Domain Privileges Returned
U1	Null or empty	Not applicable	Not applicable	All
U2	Exists	Yes	Domain privilege equal to or higher	Based on level in domain ACE
U3	Exists	Yes	Domain privilege lower	None
U4	Exists	Yes plus @	Domain privilege lower and @ privilege is higher	None (Always use domain ACE)
U5	Exists	No and no @	Not applicable	None
U6	Exists	No but @ exists	@ privilege equal to or higher	Based on level in @ ACE
U7	Exists	No but @ exists	@ privilege lower	None

Authenticated Access Examples

This section provides examples that show different levels of cross-domain calendar access.

Example 1

Table 4-2 shows an example that enables userA in domain a.com to be able to read userB's calendar in domain b.com.

Table 4-2 Example 1 Cross-Domain Access

Domain a.com	Domain b.com
LDAP entry = icsDomainNames: b.com	No icsDomainAcl defined userB's calendar has acl=[e-mail]:r

Example 2

Table 4-3 shows an example that enables [e-mail] to write to the calendar for [e-mail].

Table 4-3 Example 2 Cross-Domain Access

Domain a.com	Domain b.com
LDAP entry = icsDomainNames: b.com	LDAP entry = icsDomainAcl: @a.com:w userB's calendar has acl=[e-mail]:w

Example 3

Table 4-4 shows an example that blocks [e-mail] from writing to [e-mail]'s calendar.

Table 4-4 Example 3 Cross-Domain Access

Domain a.com	Domain b.com
LDAP entry = icsDomainNames: b.com	LDAP entry = icsDomainAcl: @a.com:r userB's calendar has acl=[e-mail]:w

Anonymous Access Overview

If there is no icsDomainAcl attribute for the target domain, all rights are returned and further checks are then done by using the calendar and scheduling ACLs.

If the target domain has an icsDomainAcl, but that ACL does not contain the @ ACE, access is denied.

If the target domain has an icsDomainAcl and the ACL contains the @ ACE and the privilege level of that ACE is higher than the requested privilege, the ACE's privilege level is returned and processing continues with the calendar and scheduling ACLs.

Table 4-5 provides more detail on anonymous access conditions and results. The Domain Privileges Returned column describes the rights that are available at the domain level and how these are used to restrict the rights allowed at the calendar and scheduling level.

Table 4-5 Anonymous Conditions and Results

1.	icsDomainAcl	@ in icsDomainAcl	Privilege Level Versus Requested Level	Domain Privileges Returned
A1	Null or empty	Not applicable	Not applicable	All
A2	Exists	No	Not applicable	None
A3	Exists	Yes	@ privilege equal to or higher	Based on level in @ ACE
A4	Exists	Yes	@ privilege lower	None