Access Control Information

Access Control Information (ACI) determines access control for calendars. Access Control Entries (ACE strings) are individual strings of control characters that are stored in LDAP as one of a calendar's properties. There can be multiple ACE strings that apply to a single calendar. Collectively, all the ACE strings that apply to a calendar are called an Access Control List (ACL). When someone has requested access to a calendar, the system searches the calendar's ACL list to check for access rights. The system uses the first ACE encountered that either grants of denies access. Thus, the ordering of an ACL is significant. ACE strings should be ordered such that the more specific ones appear before the more general ones.

Some access is “built-in”. For example, primary owners have access to everything in their calendars. The system does not need to perform access control checks for primary owners accessing their own calendars.

The WCAP Command: set_calprops command uses the acl parameter to facilitate storing of ACE strings to a calendar. The acl parameter is a semicolon-separated list of ACE strings. You can set the default acl in the ics.conf file by changing the calstore.calendar.default.acl preference, or by using the cscal command line utility.

The Command: get_userprefs command fails if any node does not have “allow anyone” access rights for reading and searching. For example, the following LDAP modify record for an ACL entry gives the correct privileges to make the command work correctly.

dn:  o=usergroup
changetype: modify
add: aci
aci: (targetattr="icscalendar ||cn||givenName||sn||uid||mail")
     (targetfilter=(objectClass=icscalendaruser))
     (version 3.0; acl "Allow calendar administrators to proxy-product=ics,
      class=admin,num=2,version=1" allow (proxy) 
      groupdn="ldap:///cn=Calendar Administrators,ou=Groups,o=usergroup";)

Here is an example of an ACE string:

jdoe^c^wd^g

The string has four elements separated by three ^characters. The four elements are:

1. The first element of an ACE tells who the ACE applies to.

   This could be an individual user (specified by user ID), a domain, or a class-type of user. The four types of classes for users are the following:

   • All users, represented by the string “@”.

     • Primary owners of a calendar, represented by the string “@@p”.

     • Owners of a calendar, represented by the string “@@o”.

     • Non-owners of a calendar, represented by the string “@@n”.

2. The second element of an ACE indicates what the ACE applies to.

   The ACE can be applied to:

   • The entire calendar.

     Applies to both components and calendar properties. To indicate the entire calendar, pass in the value a.

     • The components only.

       Applies to calendar components, that is, events and todos. To indicate just the components, pass in the value c.

     • The calendar properties only.

       Applies to calendar properties, for example, display name, or ownerlist. To indicate calendar properties only, pass in the value p.

3. The third element of an ACE indicates what access values the ACE applies to.

   Multiple values can be specified at the same time. To do this, the caller must pass in a string to indicate which bits to check.

   The table that follows lists the Access Control characters used in ACE strings. The third element contains a string with one or more of the Access Control characters.

   Access Control Characters	Description
   d	Grants the user delete access.
   f	Grants the user free-busy access.
   r	Grants the user read access.
   s	Grants the user schedule access. This means that requests can be made, replies accepted, and other ITIP scheduling interactions honored.
   w	Grants the user write access. This includes adding new items, deleting items, and modifying existing items.

   For example, to grant read access, the value r is passed in. To grant write and delete access, the value wd is passed in.

4. The fourth element of an ACE indicates whether to grant or deny access.

   The ACE can either grant or deny access.

   • To grant access, set the value to g.

     • To deny access, set the value to d.

ACE Summary

Here is a quick summary of the order of an ACE:

who ^ flags ^ how ^ grant

Where:

• who = A string, type (str).

• flags = One of the characters c, p, or a.

• how = An access-string composed of one or more of the access control characters described earlier in Access Control Information.

• grant = One of the characters g, or d

Extended Examples

Here are some examples of circumstances and how the ACE would be set in the acl parameter for the jdoe calendar:

• To grant john read access to both components and calendar properties (acl=john a r g), and to grant susan write and delete access to components only (acl=susan c wd g), the entire command is:

set_calprops.wcap?id=${SESSIONID}
             &calid=jdoe&acl=john^a^r^g;susan^c^wd^g

• To grant all users in a domain schedule, free-busy, and read access to a calendar (@domainname a sfr g), to grant owners write and delete access to components only (@@o c wd g), to grant owners self-administration rights, and schedule, free-busy, and read access to both components and calendar properties (@@o a zsfr g), to deny susan all access to both components and calendar properties (susan a zsfdwr d), and to grant read access to all users (@ c r g), the entire command is:

set_calprops.wcap?id=${SESSIONID}&calid=jdoe
                                 &acl=@domainname^a^sfr^g;
                                      @@o^c^wd^g;
                                      @@o^a^zsfr^g;
                                      susan^a^zfsdwr^d;
                                             @^c^r^g

An administrator can override the access control of all WCAP commands if he is logged in as administrator and the server configuration preference service.admin.calmaster.overrides.accesscontrol is set to “yes” in the ics.conf file.

Mapping User Interface Operations to ACL's