Sun Java System Calendar Server 6.3 WCAP Developer's Guide

Calendar Access Control Information (ACI)

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 set_calprops.wcap 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 get_userprefs.wcap 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")
     (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:


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 


    Grants the user delete access. 

    Grants the user free-busy access. 

    Grants the user read access. 

    Grants the user schedule access. This means that requests can be made, replies accepted, and other ITIP scheduling interactions honored. 

    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.

Calendar Access Control Entry (ACE) Summary

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

who ^ flags ^ how ^ grant


Note –

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.

Example 2–1 Examples

This section shows some examples of how the ACE would be set in the acl parameter for the jdoe calendar:



Mapping User Interface Operations to ACL's

User Interface Option 

ACL Required 



Delete Events and Todos 

Modify Events and Todos  

and Delete Components or, Delete Calendar 




To delete events or todos, you need modify permission, and either delete components or delete calendar permission. 

Delete Events and Todos 

Modify Events and Todos, and Delete Components  

or, Delete Calendar 




To delete events or todos, you need modify permission, and either delete components or delete calendar permission. 


Free-busy Components or 

Free-busy Calendar 



To view a free-busy representation of a calendar (the events and todos), you need free-busy components or free-busy calendar permission. 

Modify Events and Todos 

Read Events and Todos, and Write Components 

or, Write Calendar 



To modify components of a calendar (events and todos), you need read permission, and either write components or write calendar permission. 

Read Events on a Calendar 

Read Calendar 


To read components, you must have read calendar permission. 

Note that read components permission (c^r^g) does not work. 

Schedule (Invite) 

Schedule Calendar 


To invite someone, you need schedule calendar permission. 


Read Properties 


To subscribe to a calendar, you must have read properties permission.