Calendar Server 使用访问控制列表 (Access Control List, ACL) 来确定日历、日历属性和日历组件(例如事件和待办事项(任务))的访问控制。
本节包含以下主题:
用户通过 Communications Express 登录 Calendar Server 时,默认情况下验证进程并不加密登录信息(包括用户名和密码)。如果希望增加站点登录的安全性,请配置 Calendar Server 使用安全套接口层 (Secure Sockets Layer, SSL) 协议来加密登录数据。有关更多信息,请参见第 7 章,配置 SSL,配置 SSL。
确定对日历、日历属性和日历组件的访问权限时,Calendar Server 将考虑以下用户:
主要日历所有者
主要日历所有者对自己的日历拥有完全访问权限。Calendar Server 不对主要所有者访问自己的日历执行任何访问控制检查。
管理员和超级用户
管理员(例如 calmaster)或超级用户(例如 root)不受访问控制限制,可以对日历或日历组件执行任何操作。有关更多信息,参见1.3 Calendar Server 版本 6.3 的特殊帐户。
其他日历所有者
主要日历所有者可以为自己的日历指定其他所有者。这样,其他所有者就可以代表主要所有者安排、删除、修改、接受或谢绝事件或待办事项(任务)。
anonymous 用户
如果 ics.conf 文件中的 service.http.allowanonymouslogin 设置为 yes(默认值),那么特殊的日历 ID (calid) anonymous 就可以使用任何密码访问 Calendar Server。anonymous 用户不与任何特定域相关联。用户可以通过编辑 calstore.anonymous.calid 参数来更改 anonymous 用户的 calid。
如果日历的权限设置为允许任何人进行读访问,那么您也可以匿名查看日历。例如,以下链接允许用户匿名查看 calid 为 tchang:meetings 的日历(如果该日历的权限设置为允许任何人进行读访问):
http://calendar.sesta.com:8080/?calid=tchang:meetings
anonymous 用户可以查看、打印和搜索日历中的公共事件和任务,但不能执行任何其他操作。
有关匿名查看资源日历的信息,参见15.8 创建日历链接。
Calendar Server 使用访问控制列表 (Access Control List, ACL) 来确定日历、日历属性和日历组件(例如事件和待办事项(任务))的访问控制。ACL 由一个或多个访问控制条目 (access control entry, ACE) 组成,这些条目是共同应用到同一个日历或组件的字符串。ACL 中的每个 ACE 之间必须用分号分隔。
以下为一组示例:
jsmith^c^wd^g 由单个 ACE 组成。
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g 由三个 ACE 组成。
ACE 由以下元素组成,每个元素之间由插入符号 (^) 分隔:
1.8.3.1 Calendar Server 版本 6.3 中的 Ace 字符串的 Who 元素 - 应用 ACE 的个人、用户、域或用户类型。
1.8.3.2 Calendar Server 版本 6.3 中的 Ace 字符串的 What 元素 - 被访问的目标,例如日历、日历组件(如事件、待办事项(任务))或日历属性。
1.8.3.3 Calendar Server 版本 6.3 中的 Ace 字符串的 How 元素 - 允许的访问控制权限的类型(例如读、写或删除)。
1.8.3.4 Calendar Server 版本 6.3 中的 Ace 字符串的 Grant 元素 - 已授予或拒绝授予的特定访问控制权限。
例如,在 ACE jsmith^c^wd^g 中:
jsmith 是 Who 元素,表示将应用 ACE 的人。
c 是 What 元素,表示要访问的内容(仅日历组件)。
wd 是 How 元素,表示要授予或拒绝授予的访问权限(写和删除)。
g 是 Grant 元素,表示已授予 jsmith 对日历组件的指定访问权限(写和删除)。
Who 元素是 ACE 中的主要值,表示将应用 ACE 的人(例如单个用户、域或特定类型的用户)。
Who 也称为通用主要名称 (UPN)。用户的 UPN 是用户的域和登录名的组合。例如,域 sesta.com 中的用户 bill 的 UPN 为 bill@sesta.com。
表 1–2 访问控制条目 (ACE) 字符串中的 "Who" 格式
What 元素指定要访问的目标,例如日历、日历组件(事件或任务)或日历属性。
表 1–3 访问控制条目 (ACE) 字符串中的 "What" 值
值 |
说明 |
|
---|---|---|
|
指定日历组件,例如事件和任务 |
|
|
指定日历属性,例如名称、说明和所有者等 |
|
|
指定整个日历(所有内容),包括组件和属性 |
How 元素指定允许的访问控制权限的类型,例如读、写或删除。
表 1–4 访问控制条目 (ACE) 字符串中的 "How" 类型
类型 |
说明 |
---|---|
r |
读访问。 |
w |
写访问,包括添加新项和修改现有项。 |
d |
删除访问。 |
s |
预定(邀请)访问。可以发送请求、接受回复以及进行其他 ITIP 预定交互操作。 |
f |
仅空闲/繁忙(空闲时间)访问。空闲/繁忙访问表示用户能够查看日历中的时间安排,但不能查看事件的详细信息。已预定的时间块将只显示“不可用”。未预定任何事件的时间块旁边将显示“可用”。 |
l |
域的查找访问。 |
e |
以代表身份进行回复访问。此类型授予用户代表日历的主要所有者接受或拒绝邀请的权限。此访问类型不需要明确授予,因为当一名用户被指定为日历的所有者(非主要所有者)时,就暗含授予了这种权限。 |
i |
以代表身份进行邀请访问。此类型授予用户代表日历的主要所有者创建和修改已邀请其他参与者的组件的权限。此访问类型不需要明确授予,因为当一名用户被指定为日历的所有者(非主要所有者)时,就暗含授予了这种权限。 |
c |
以代表身份进行取消访问。此类型授予用户代表日历的主要所有者取消已邀请其他参与者的组件的权限。此访问类型不需要明确授予,因为当一名用户被指定为日历的所有者(非主要所有者)时,就暗含授予了这种权限。 |
z |
自我管理访问—授予已经验证的用户添加和删除访问控制条目的权力。拥有该权限的用户可以添加和删除自身的权限。例如,UserA 可能不具有对 UserB 的日历的写访问权限,但是 UserA 被授予了对 UserB 的日历的自我管理访问权限。因此,UserA 可以添加一条访问控制条目,授予自己对 UserB 的日历的写访问权限。 备注:UserA 不能使用该权限授予其他用户对 UserB 的日历的访问权限。例如,自我管理权限不允许 UserA 授予 UserC 对 UserB 的日历的访问权限。 |
Grant 元素指定是授予还是拒绝授予指定的访问类型,例如 d(删除)或 r(读取)。
表 1–5 访问控制条目 (Access Control Entry, ACE) 字符串中的 Grant 值
值 |
说明 |
---|---|
g |
授予特定的访问控制权限。 |
d |
拒绝授予特定的访问控制权限。 |
以下示例显示了 ACE 的用法:
授予用户 ID jsmith 对整个日历(包括组件和属性)的读取访问权限:
jsmith^a^r^g
授予 jsmith 仅对组件的写和删除访问权限:
jsmith^c^wd^g
授予 sesta.com 域中的所有用户仅对组件的预定、空闲时间和读取访问权限:
@sesta.com^c^sfr^g
授予所有所有者仅对组件的写和删除访问权限:
@@o^c^wd^g
拒绝授予 jsmith 对日历数据的所有访问权限:
jsmith^a^sfdwr^d
授予所有所有者对整个日历(包括组件和属性)的读、预定和空闲时间访问权限:
@@o^a^rsf^g
授予所有用户读访问权限:
@^a^r^g
在 Calendar Server 读取 ACL 时,它会使用遇到的第一个 ACE,无论其是授予还是拒绝授予对目标的访问权限。因此,ACL 条目的顺序非常重要。对 ACE 字符串排序时,应将明确具体的条目放在概括性条目之前。
例如,假设日历 jsmith:sports 的 ACL 中的第一个 ACE 将读访问权限授予所有用户。然后,Calendar Server 遇到的第二个 ACE 拒绝授予 bjones 对此日历的读访问权限。在这种情况下,Calendar Server 将授予 bjones 对此日历的读访问权限,而忽略第二个 ACE,因为它与第一个 ACE 冲突。因此,要确保实现特定用户(例如 bjones)的访问权限,应将 bjones 的 ACE 放在 ACL 中全局性较强的条目(例如,应用于日历的所有用户的 ACE)之前。