User:Kanarip/Draft:Kolab LDAP Schema Extensions
From Kolab Wiki
KEP : Kolab LDAP Schema Extensions
|Author||Jeroen van Meeuwen|
|Latest Working Copy||KEP-0000.txt|
The Kolab Groupware solution is heavily based around LDAP functionality, and more specifically OpenLDAP. While OpenLDAP ships, alongside the software, a limited number of LDAP schemas, additional functionality has been provided through LDAP schema extensions specific to Kolab.
However, these LDAP Schema extensions duplicate large amounts of objectClass and attributeType functionality already provided by LDAP server software NOT OpenLDAP, including but not limited to;
- Novell eDirectory
- Red Hat Directory Server
- Netscape Directory Server
- Sun Directory Server
- 389 Directory Server
and possibly including, to a lesser extent;
- IBM Lotus Domino Directory Server
- Microsoft Active Directory
- Open Directory Server
Since LDAP directories are built to last, and loading additional schemas creating duplicate functionality for multiple objects is often not considered the most sustainable way to deploy a new environment such as a Kolab Groupware environment, it makes sense to redefine the LDAP Schema extensions Kolab Groupware requires.
The implementation and acceptance of this KEP will cause the Kolab LDAP schema extensions to be released in the following formats:
- LDIF Compatible,
- RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions 
Kolab objects referred to in this document are defined in KEP #7: Definitions of Kolab Objects.
Registered OID Prefix
The registered OID prefix is 126.96.36.199.4.1.19414.
The naming convention is to prefix all objectClasses and attributeTypes with 'kolab'.
Exceptions to this rule may apply, such as the alias attribute defined in the OpenLDAP schema extensions.
Kolab User Accounts
Distinguishing types of account objects in LDAP is a prerequisite to successful Kolab deployment. In the simplest case, no account that is in a certain tree branch is not also a Kolab User. To illustrate, the following example;
dc=example,dc=org `- ou=Groups `- ou=Accounts `- ou=Users `- uid=jdoe `- ou=Services `- uid=apache
Given the following conditions, no additional schema extensions would be required;
- No external user accounts exist in the LDAP tree,
- All user accounts reside under ou=Users,ou=Accounts,dc=example,dc=org (or, in other words, all users reside under a specific organizational unit, and no objects other then users reside under that organizational unit),
- All user accounts are also Kolab users.
However, some Kolab Groupware functionality is implemented using LDAP Schema extensions, that we are not willing to lose.
As such, we require schema extensions that allow these attributes to be defined for Kolab users.
For large deployments, with all possible account types and possibly a few more, imagine the following illustrative example directory tree exists;
dc=example,dc=org `- ou=Groups `- ou=Accounts `- ou=Users `- uid=jdoe # Kolab user `- uid=jsixpack # Microsoft Exchange user `- uid=mimum # Not a groupware user `- ou=Services `- uid=apache
The Kolab user requires a set of objectClasses, attributeTypes and/or attribute values -anything that can build a unique triplet of base dn, search scope and search filter- that can clearly distinguish this user from other users for the purposes of authentication and authorization, as well as to allow the Kolab Daemon to pick up only the true positives.
Without any schema extensions applied to the user object, the attribute that describes the mail server could be used, but this doesn't scale very well (the search for all Kolab users would need to include a filter for all mail servers).
It therefore makes sense to extend the LDAP Schema, though the extension only requires providing minimal additional functionality. This objectClass could be;
objectClasses: ( 188.8.131.52.4.1.194184.108.40.206 NAME 'kolabInetOrgPerson' DESC 'Kolab Internet Organizational Person' SUP top AUXILIARY )
This also allows us to add some attributes providing additional Kolab Groupware features:
Delegation of one's Kolab account means to say, that user A allows user B to 'send on behalf of'. A popular form of delegation is also to not give out access to the INBOX of user A, but instead copy user B on messages of a particular type (such as invitations and confirmations).
The following configuration needs to be stored in LDAP, because the original user, the target user and the Kolab Groupware system services need to be aware of the configuration:
- The user whom is the delegate
- The policy to use in delegating
Invitation Handling Policies
Sender Access Policy
Allow the senders listed / matched to send to this recipient.
Recipient Access Policy
Allow the sender to send to the recipient listed / matched.
This document is placed in the public domain.