A Kolab deployment is unique in that it requires one application (say, webmail) to login to another application (say, IMAP, or LDAP, or SMTP) with credentials that match that of the originating user.

That is to say that a user john.doe@example.org logging in to webmail is functionally no different for IMAP, LDAP, SMTP, and the likes of those, than that very same user logging in to those services directly (without the use of a webmail application).

This necessitates either of the following three scenarios:

1. The user's credentials are stored in the application consuming other applications, in that Roundcube for example requires the use of the original username and password whenever it wants to log in to IMAP, LDAP, SMTP, and so forth.
2. The application consuming other applications on the user's behalf uses proxy authorization -- this is the concept of using privileged credentials to authenticate, with the request to be treated as if another user had logged in. In principle, this scenario constitutes privilege escalation (followed by de-escalation) and is a scenario we've sought to avoid at all cost.
3. A constitutional free-for-all opens up the environment and data in that environment to all parties equally.

It has also meant that sharing with third parties as become near to impossible; a third party could not, with the best intentions, authenticate as one-self.

It has also meant a decline in the feasibility of applying, truly securely, second-factor authentication.

It has also meant a decline in the feasibility of becoming an authentication provider (such as OpenID or OAuth).

These topics deserve addressing and necessitate the evaluation of what is otherwise known as CAS (Central or Centralized Authentication Services).