[Kolab-devel] Shared Folders, ACLs and LDAP Schema (was: Re: Changes to master branch)

[Jeroen van Meeuwen (Kolab Systems)]

Mathieu Parent wrote:
> Hello,
> 

Hi Mathieu,

> > - split out the kolab schema, because that is a dev/release cycle of its
> > own completely (backwards, forwards compatibility, deemed stable in the
> > very long-term, should not be changed lightly, etc.)
> 
> This is an opportunity for "kolab/issue3488 (kolabSharedFolder and
> kolabGroupOfNames should be AUXILIARY)"
> 

I've given it some more thought, and while I think I understand the use-case I 
also think things are being interchanged as if they were the same thing, while 
they are not.

In kolab/issue3343, the 'mail' attribute contains a 'mail domain name space' 
(e.g. 'example.com').

What Cyrus IMAP wants appended to the folder name however is the 
'authentication realm' (read, actually: the authorization realm).

Kolab at this moment seems to disregard both and uses whatever it finds in the 
distinuished name for the object, creating a folder that is 
shared/info at example.com for a set of domain components dc=example,dc=com, and 
shared/info at domain.local for domain components dc=domain,dc=local, inherently 
using the domain components of the dn in the LDAP directory tree as if it 
represents the authn/authz realm. This is just plain wrong.

Given the existance and application of the virtdomains-ldap patch, however, 
users can now authenticate using their uid or email address, and as such be 
authorized within the domain name space of their email address, as opposed to 
their (original) authorization realm. This, too, is just plain wrong, since 
the email address for one user can be set to effectively result in 
authorization in an entirely different realm; Example:

LDAP Admin sets mail attribute for 
uid=jdoe,customer=novell.com,dc=hosting,dc=provider to info at sco.com. User jdoe 
authenticates and is now authorized as info at sco.com.

Different means to achieve the same goal are available, and less of a 
fundamental security breach.

The domain name space for an email address and the name of a realm being 
interlinked within Cyrus IMAP is just plain wrong as well; a realm is 
something different then a domain name space even though they may have the 
same value. See also the confusing 'defaultdomain' vs. 'loginrealms' settings.

The question now becomes, how do we resolve this? I love looking forward.

We can't continue to use the dn components to compose something, of that I am 
fairly certain.

We can use the email address for now, but I think this is only a viable 
solution for the short term - the email address does not necessarily contain 
the authorization realm.

That said, if you can rebase the patch against the master branch on 
git://git.kolab.org/git/perl-Kolab (please insert commentary as appropriate), 
I'll accept it.

Ultimately, I think, the use of email addresses to authenticate and authorize 
should be re-assessed and possibly re-implemented. We wouldn't happen to have 
any enthousiastic C coders available now, have we? Since I'm now the release 
engineer for both Cyrus IMAP and SASL, surely we must be able to push some 
quality code through relatively quickly.

A mechanism like ptclient/ldap.c could be (amended and) used to "re-authorize" 
authenticated users as something other then their login (think along the lines 
of authorizing as @company.com while their email address is @emea.company.com 
or even @company.co.uk). That along with cross-realm ACL support with some 
form of mandatory access control, I think, would build us a more sustainable 
solution.

If somebody is interested, please stand up!

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110416/1eed22c8/attachment.html>