Chapter 4
Managing Calendar Server Access Control

Sun™ ONE Calendar Server uses Access Control Lists (ACLs) to determine the access control for calendars, calendar properties, and calendar components such as events and todos (tasks).

This chapter contains these sections:

Secure Calendar Server Logins
Access Control by Users
Access Control Lists (ACLs)
Public and Private Events and Tasks Filter
Proxy Administrator Logins
Configuration Parameters for Access Control
Command-Line Utilities for Access Control

---

Secure Calendar Server Logins

When users log in to Calendar Server through Calendar Express, by default the authentication process does not encrypt the login information, including user names and passwords. If you want secure logins as your site, configure Calendar Server to use the Secure Sockets Layer (SSL) protocol to encrypt the login data. For more information, see Chapter 9, "Using SSL With Calendar Server."

---

Access Control by Users

Calendar Server considers the following users when determining access to calendars, calendar properties, and calendar components:

Primary calendar owners

Primary calendar owners have full access to their own calendars. Calendar Server does not perform any access control checks for primary owners accessing their own calendars.

Administrators and superusers

An administrator such as icsuser or calmaster, or a superuser such as root, is not subject to access control restrictions and can perform any operation on a calendar or calendar component. For more information, see "Calendar Server Administrators".

Other calendar owners

Primary calendar owners can designate other owners for their calendars. The other owner can then act on behalf of the primary owner to schedule, delete, modify, accept, or decline events or todos (tasks) for a calendar.

anonymous user

The special calendar ID (calid) anonymous can access Calendar Server using any password, if service.http.allowanonymouslogin in the ics.conf file is set to “yes” (which is the default). The anonymous user is not associated with any particular domain.You can change the calid for the anonymous user by editing the calstore.anonymous.calid parameter.

You can also view a calendar anonymously if the calendar’s permissions allow read access for everybody. For example, the following link allows users to anonymously view the calendar with the calid tchang:meetings (if the calendar’s permissions allow read access for everybody):

http://calendar.sesta.com:8080/?calid=tchang:meetings

An anonymous user can view, print and search for public events and tasks on the calendar but cannot perform any other operations.

For information about viewing a resource calendar anonymously, see Linking to a Calendar.

---

Access Control Lists (ACLs)

Calendar Server uses access control lists (ACLs) to determine access control for calendars, calendar properties, and calendar components such as events and todos (tasks). An ACL consists of one or more access control entries (ACEs), which are strings that collectively apply to the same calendar or component Each ACE in an ACL must be separated by a semicolon.

Note: ACE characters are case insensitive. The default is expressed in lower case, but you will see uppercase for any characters modified through the Calendar Express GUI. No special meaning is attached to either upper or lower case.

For example:

jsmith^c^wd^g consists of a single ACE.
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g consists of three ACEs.

An ACE consists of the following elements, with each element separated by a caret (^):

Who - The individual, user, domain, or type of user who the ACE applies to.
What - The target being accessed, such as a calendar or a calendar component such as an event, todo (task), or calendar property.
How - The type of access control rights permitted, such as read, write, or delete.
Grant - A specific access control right that is either granted or denied.

For example, in the ACE jsmith^c^wd^g:

jsmith is the Who element, indicating who the ACE applies to.
c is the What element, indicating what is being accessed (only the calendar components).
wd is the How element, indicating which access rights are to be granted or denied (write and delete).
g is the Grant element, indicating that the specified access rights, write and delete, for the calendar components are granted to jsmith.

Who

The Who element is the principal value for an ACE and indicates who the ACE applies to, such an individual user, domain, or specific type of user.

Who is also called the Universal Principal Name (UPN). The UPN for a user is the user’s login name combined with the user’s domain. For example, user bill in domain sesta.com has the UPN bill@sesta.com.

Table 4-1 shows the Who formats used in Calendar Server ACEs.

Table 4-1  Who Formats for Access Control Entry (ACE) Strings 

Format	Description
user	Refers to a specific user. For example: jsmith.
user@domain	Refers to a specific user at a specific domain. For example: jsmith@sesta.com.
@domain	Refers to any user at the specified domain. For example: @sesta.com specifies jsmith@sesta.com, sally@sesta.com, and anyone else at sesta.com. Use this format to grant or deny access to an entire domain of users.
@	Refers to all users.
@@{p|o|n}	Refers to owners for the calendar: @@p – primary owner only @@o – all owners, including the primary owner @@n – not an owner

What

The What element specifies the target being accessed, such as a calendar, calendar component (event or task), or calendar property.

Table 4-2 shows the What target values used in Calendar Server ACEs.

Table 4-2  What Values for Access Control Entry (ACE) Strings 

Value	Description
c	Specifies calendar components such as events and tasks
p	Specifies calendar properties such as name, description, owners, and so forth
a	Specifies an entire calendar (all), including both components and properties

How

The How element specifies the type of access control rights permitted, such as read, write, or delete.

Table 4-3 shows the How types of access control rights used in Calendar Server ACEs.

Table 4-3  How Types for Access Control Entry (ACE) Strings 

Type	Description
r	Read access.
w	Write access, including adding new items and modifying existing items.
d	Delete access.
s	Schedule (invite) access. Requests can be made, replies will be accepted, and other iTIP scheduling interactions will be honored.
f	Free/busy (availability) access only. Free/busy access means that a user can see scheduled time on a calendar, but is not allowed to see the event details. Instead, only the words “Not Available” appear by a scheduled time block. Blocks of time without any scheduled events are listed with the word “Available” next to them.
l	Lookup access for a domain.
e	Act on behalf of for reply access. This type grants a user the right to accept or decline invitations on behalf of the calendar’s primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.
i	Act on behalf of for invite access. This type grants a user the right to create and modify components in which other attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.
c	Act on behalf of for cancel access. This type grants a user the right to cancel components to which attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.

Grant

The Grant element specifies whether to grant or deny access for a specified access type, such as d (delete) or r (read).

Table 4-4 shows the Grant attribute values used in Calendar Server ACEs.

Table 4-4  Grant Values for Access Control Entry (ACE) Strings 

Value	Description
g	Grant the specific access control right.
d	Deny the specific access control right.

Examples of ACEs

The following examples show the use of ACEs:

Grant the user ID jsmith read access to the entire calendar, including both components and properties:

jsmith^a^r^g

Grant jsmith write and delete access to components only:

jsmith^c^wd^g

Grant all users in the sesta.com domain privileges to schedule, availability, and read access to components only:

@sesta.com^c^sfr^g

Grant all owners write and delete access to components only:

@@o^c^wd^g

Deny jsmith all access to calendar data:

jsmith^a^sfdwr^d

Grant all owners read, schedule, and availability access to the entire calendar, including both components and properties:

@@o^a^rsf^g

Grant read access to all users:

@^a^r^g

Placing ACEs in an ACL

When the Calendar Server reads an ACL, it uses the first ACE it encounters that either grants or denies access to the target. Thus, the ordering of an ACL is significant, and ACE strings should be ordered such that the more specific ones appear before the more general ones.

For example, suppose the first ACE in an ACL for the calendar jsmith:sports grants read access to all users. Then, Calendar Server encounters a second ACE that denies bjones read access to this calendar. In this case, Calendar Server grants bjones read access to this calendar and ignores the second ACE because it is a conflict. Therefore, to ensure that an access right for a specific user such as bjones is honored, the ACE for bjones should be positioned in the ACL before more global entries such as an ACE that applies to all users of a calendar.

---

Configuration Parameters for Access Control

Table 4-5 describes the configuration parameters in the ics.conf file that Calendar Server uses for access control. For more information see Chapter 12, "Calendar Server Configuration Parameters".”

Table 4-5  Access Control Configuration Parameters 

Parameter	Description
calstore.calendar.default.acl	Specifies the default access control settings used when a user creates a calendar. The default is: "@@o^a^r^g;@@o^c^wdeic^g;@^a^fs^g;@^c^^g;@^p^r^g"
calstore.calendar.owner.acl	Specifies the default access control settings for owners of a calendar. The default is: "@@o^a^rsf^g;@@o^c^wdeic^g".
resource.default.acl	Specifies the default access control settings used when a resource calendar is created. The default is: "@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

---

Public and Private Events and Tasks Filter

When creating a new event or task, a user can specify whether the event or task is Public, Private, or Time and Date Only (confidential):

Public—Anyone with read permission to the user’s calendar can view the event or task.
Private—Only owners of the calendar can view the event or task.
Time and Date Only (confidential)—Owners of the calendar can view the event or task. Other users with read permission to the calendar can see only “Untitled Event” on the calendar, and the title is not an active link.

The calstore.filterprivateevents determines whether Calendar Server filters (recognizes) Private and Time and Date Only (confidential) events and tasks. By default this parameter is set to “yes”. If you set calstore.filterprivateevents to “no”, Calendar Server treats Private and Time and Date Only events and tasks as if they are Public.

---

Proxy Administrator Logins

To allow administrator proxy logins for Calendar Server, perform these steps:

In the ics.conf file set, the following parameter:

service.http.allowadminproxy = "yes"

Restart Calendar Server for the new value to take effect.
Verify that administrator proxy logins are working by using the following WCAP command:

http://server[:port]/login.wcap?user=admin-user
&password=admin-password&proxyauth=calendar-user

where:

server is the name of the server where Calendar Server is running.
port is the Calendar Server port number. The default port is 80.
admin-user is the Calendar Server administrator. For example, calmaster.
admin-password is the password for admin-user.
calendar-user is the calid of the Calendar Server user.

If the command is successful, Calendar Server displays the calendar for calendar-user. If problems occur, Calendar Server displays “Unauthorized”. Causes might be:

The admin-user does not have Calendar Server administrator privileges.
The admin-password is incorrect.
The calendar-user is not a valid Calendar Server user.

 

---

Command-Line Utilities for Access Control

Table 4-6 describes the Calendar Server command-line utilities that allow you to set or modify ACLs for access control:

Table 4-6  Command-Line Utilities for Access Control

Utility	Description
cscal	Use the create and modify commands with the -a option to set ACLs for specific user’s calendars.
csresource	Use the create command with the -a option to set ACLs for resource calendars for resources such as conference rooms or equipment.
csuser	Use the csuser utility with the -a option to manage calendar user information stored in an LDAP directory server and the calendar database.

Previous      Contents      Index      Next

---

Copyright 2003 Sun Microsystems, Inc. All rights reserved.