summaryrefslogtreecommitdiff
path: root/KEP-0007.txt
blob: 17641d7cd63e4e08c37d2ffc664fcc64c25ae14a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
{{kep
 |number=7
 |ticketnumber=
 |title=Definitions of Kolab Objects
 |author=Jeroen van Meeuwen
 |author_email=vanmeeuwen@kolabsys.com
 |status=draft
 |type=informational
 |creation_date=2011-04-14
 |obsoletes=
 |obsoleted_by=
 |related=
}}

== Abstract ==

The Kolab Groupware solution is heavily based around LDAP functionality, and more specifically OpenLDAP.

To smooth future integration with other LDAP server technology and to abstract the functionality Kolab Groupware requires from an Authentication and Authorization Database, and to outline the parameters for future development, this Kolab Enhancement Proposal has been created to outline just those parameters by defining the Kolab Objects.

== Object Classification ==

The objects defined in this document are classified to reflect the importance of their existence to a Kolab Groupware environment. In future references, these classifications could be used to, for example, split up mandatory, recommended and optional LDAP schema extensions or SQL database schema definitions.

The classifications are defined as follows;

; '''Primary'''
: These are the objects without which no Kolab Groupware solution can be deployed.
; '''Secondary'''
: These are the objects that make a Kolab Groupware deployment the platform for collaboration, and enrich the user's experience interacting with the Kolab Groupware environment.
; '''Tertiary'''
: These are the objects related to larger Kolab Groupware deployments and may or may not apply to a certain implementation scenario.
; '''Quaternary'''
: These objects are organization specific.

== Primary Objects ==

The following primary Kolab Objects are defined in this document;

* Account
* Group

=== Account ===

An account consists of, at the very least, half of a set of authentication credentials, the ''username''. In typical deployments, two parts of the authentication credentials are stored with an account; the ''username'' and ''password''.

An account in itself does not necessarily specify '''what type of account''' the entry represents. Types of accounts may include, but are not limited to;

; Administrator Account
: For example, ''cn=Directory Manager''
; External User Account
: For example, ''bugzilla-user@tailspintoys.com''
; General User Account
: For example, ''temp-hire@example.org''
; Kolab User Account
: For example, ''employee@example.org''
; Service Account
: For example, ''svc-bugzilla''

Certain policies may apply to one type of accounts, most commonly user accounts, such as password expiry, complexity requirements or recipient policies. Additionally, service accounts usually do not use an email address coupled to their service account username.

Accounts associated with persons usually have the following attributes defined as mandatory;

; Given name
: For example, ''John''
; Surname
: For example, ''Doe''

More attributes may be considered, or have been defined as mandatory. These however may be generated using the input on the former mandatory attributes;

; Display name
: For example ''Doe, John'', ''Doe, J.'', ''John Doe'' or ''J. Doe''. Typically, this is how the user account shows up as a contact in global address book searches.
; Email address
: For example ''j.doe@example.org'' or ''john@example.org''
; Username
: For example ''jdoe''

=== Group ===

At the very minimum, a group consists of an identifier. In order for it to be eligible as a group, it probably allows members to be added and removed from the group.

Different types of groups may include;

; Distribution Group
: This is the type of group that is used for distribution of information. In a typical user interaction flow, upon selection from an address book, a distribution group expands to the addresses of the actual members of the group.
; Security Group
: A security group on the other hand is used for access control and authorization purposes.

In some deployment scenarios, members have security group membership levels allowing them to add, modify or remove other members to, in or from the security group, respectively.

A group is not necessarily of one type '''or''' the other. A security group may very well also be used as a distribution group. However, by their very nature, security groups are not supposed to show up in address books '''unless''' they are also distribution groups.

The use of either type of groups is different, however. For a distribution group, typically the email address attribute for the member of the group is used, whereas with a security group, the authorization typically uses the username for the member of the group.

== Secondary Objects ==

The following secondary Kolab Objects are defined in this document;

* Distribution List
* Resource
* Shared Folder

=== Distribution List ===

A stub address book entry for mail-enabled processing software, such as mailing list software ''mailman'' or ''majordomo''. Not to be confused with a ''Contact'' defined as a quaternary object, as Distribution Lists tend to be for internal use only, but even in cases they are not, have submission access policies.

=== Resource ===

An object representing an object such as a beamer, conference room or a car.

=== Shared Folder ===

Shared Folders are usable as valid target recipients, and should thus be included in the Authorization and Authentication database, with the attributes applicable (for example the email address).

== Tertiary Objects ==

The following tertiary Kolab Objects are defined in this document;

* Class of Service
* Domain
* Host

=== Class of Service ===

A CoS may be used to define a set of common settings for users and/or groups. Such CoS may define default values for other objects, such as quota or recipient policies.

=== Domain ===

A domain -not to be confused with a realm defined as a quaternary object- as is used in relation to Kolab Groupware actually represents a mail domain, and implicitly refers to a domain name space rather then a domain.

=== Host ===

A host is a node, or ''operating system instance''. In relation to Kolab Groupware, nodes participate in the Kolab Groupware environment.

== Quaternary Objects ==

The following quaternary Kolab Objects are defined in this document;

* Calendar
* Contact
* Contact List
* Mail Accounts
* Realm
* Miscellaneous

=== Calendar ===

Used to refer to an external (non-Kolab) calendar.

=== Contact ===

A mail or instant messaging contact. Usually refers to an entity external to the organization.

=== Contact List ===

A list of contacts used as a permanent filter or search, for example ''All Kolab Users'', or ''All Receptionists''.

=== Mail Accounts ===

Mail accounts external to the organization, to be polled for new email that may or may not be fetched and delivered locally.

=== Realm ===

A realm, not to be confused with a domain, is an authentication and authorization namespace. Applicable to deployment scenarios implementing Kerberos authentication.

=== Miscellaneous ===

Any other object type, for example, ''kolabGermanBankArrangement''

== References ==

{{Reflist}}

== Copyright ==

This document is placed in the public domain.