This more specifically involves a multi-domain deployment for which the services such as are addressed over the same URI, such as is often the case for a Hosted Kolab deployment.

The original problem space seems to be one single human being opening up two connections to WebDAV with the intent to use a different set of credentials between the first and the second, with both sets of credentials in a different domain name space aka. "authorization realm" in IMAP terminology.

• It seems not viable to make this happen for another account in the same domain name space, for this would make the HTTP Basic Authentication realm be the same realm,
• Sharing within the same domain name space would furthermore be solved by sharing the folder(s) in question, rather than through another connection.
• The cross-domain sharing is the equivalent of sharing contents with a third party.

Client applications that do not allow multiple sessions against a single (base) URI, such as a regular browser, can only be made to authenticate with different credentials using the HTTP Basic Authentication realm. However, the CalDAV and CardDAV clients I know of do allow this second connection.

Also note that the application's base URL cannot be "realmed" using the suggested methodology, such that entering "davs://webdav.example.org" will not trigger this "realming" as it's been implemented, nor will hitting "davs://webdav.example.org/files/".

In T1086#15868, @vanmeeuwen wrote:

This more specifically involves a multi-domain deployment for which the services such as are addressed over the same URI, such as is often the case for a Hosted Kolab deployment.

The original problem space seems to be one single human being opening up two connections to WebDAV with the intent to use a different set of credentials between the first and the second, with both sets of credentials in a different domain name space aka. "authorization realm" in IMAP terminology.

Correct

• It seems not viable to make this happen for another account in the same domain name space, for this would make the HTTP Basic Authentication realm be the same realm,
• Sharing within the same domain name space would furthermore be solved by sharing the folder(s) in question, rather than through another connection.

Agree.

• The cross-domain sharing is the equivalent of sharing contents with a third party.

Yes, it is.

Client applications that do not allow multiple sessions against a single (base) URI, such as a regular browser, can only be made to authenticate with different credentials using the HTTP Basic Authentication realm. However, the CalDAV and CardDAV clients I know of do allow this second connection.

There is at least one Client which does this: Mozilla Thunderbird which is a CalDAV / CardDAV Client together with AddOns like Inverse SOGo Connector.

Most other Clients I know of, save URL, Username ans Password together for each account. So there is no problem to manage multiple accounts with the same host in the URL.

Thunderbird uses a password manager which stores URL, Realm, Username and Password. To determine the correct entry in the Password Manager, it follows the RFC 7235 and uses the FQDN and Realm to find the entry (e.g. does not take the Path of the URL into account). Kolab uses always the Realm "KolabDAV".

In the context of the same FQDN multiple accounts work, as long you have the same Username for all CardDAV / CalDAV URL. But it fails if you use another Username (for example a@abc.com and b@efg.com).

Use Cases for this:

• You may have a private E-Mail Domain and a Business E-Mail Domain on the same Kolab-Server
• A Third Party wants to give you access to a specific AddressBook or Calendar and happen to be on the same Server

Also note that the application's base URL cannot be "realmed" using the suggested methodology, such that entering "davs://webdav.example.org" will not trigger this "realming" as it's been implemented, nor will hitting "davs://webdav.example.org/files/".

I can not follow your argument here. Even if you use the schema davs:, kolab uses Basic Authentication with HTTPS. So the suggested fix works, if the Client follows RFC 7235 and takes the realm into account. Note, that the realm is not part of the URL and is just sent in the HTTP-Headers.

I testet with Thunderbird with SOGo Connector, but all Add-Ons which use the passwort management of Thunderbird will probably work this way.

In T1086#16217, @pafei wrote:

In T1086#15868, @vanmeeuwen wrote:

Client applications that do not allow multiple sessions against a single (base) URI, such as a regular browser, can only be made to authenticate with different credentials using the HTTP Basic Authentication realm. However, the CalDAV and CardDAV clients I know of do allow this second connection.

There is at least one Client which does this: Mozilla Thunderbird which is a CalDAV / CardDAV Client together with AddOns like Inverse SOGo Connector.

Do you mean that you are using SOGo for both CalDAV and CardDAV? I've used Lightning for CalDAV, which does seem to allow the second connection (but my memory on this is fuzzy).

Use Cases for this:

• You may have a private E-Mail Domain and a Business E-Mail Domain on the same Kolab-Server

• A Third Party wants to give you access to a specific AddressBook or Calendar and happen to be on the same Server

These use-cases are valid, but both can be regarded to as "sharing with third parties";

• In the first use-case, the human being behind the separate identity just so happens to be the same human being.

• In the second use-case, I intend to include the broad array of third parties that are not Kolab users on the same server, and may in fact not be Kolab users at all, and should be able to authenticate nonetheless.

That being said;

If the multi-domain setup truly maintains completely separate organization hierarchies in LDAP (i.e. dc=pleasure,dc=ch vs. dc=business,dc=com), it would not be insurmountably difficult to have a single client application run off of one of multiple profiles (effectively keeping "business" and "pleasure" separate on the client system as well). Thunderbird at least supports this. Whether its connectors also do would need to be verified.

If the separation between "business" and "pleasure" does not matter that much, however, either domain could be another's alias or child domain, so that a single user account holds identities in both domain name spaces / authorization realms, and a single mailbox hierarchy resides in one or the other authorization realm. This may not fly "simply", but

The general case for sharing with third parties remains, however, and for this we would seek to adopt cross-realm or cross-domain sharing capabilities with mandatory access control, as recently introduced in Cyrus IMAP here.

With this feature adopted, a user john@doe.com could share his mailboxes with a user jane@sixpack.org, and the same would go for john.doe@pleasure.ch with john.doe@business.com (and vice-versa).

Also note that the application's base URL cannot be "realmed" using the suggested methodology, such that entering "davs://webdav.example.org" will not trigger this "realming" as it's been implemented, nor will hitting "davs://webdav.example.org/files/".

I can not follow your argument here. Even if you use the schema davs:, kolab uses Basic Authentication with HTTPS. So the suggested fix works, if the Client follows RFC 7235 and takes the realm into account. Note, that the realm is not part of the URL and is just sent in the HTTP-Headers.

My argument revolved around the standard /.well-known URLs for Calendar and Address Book discovery, at which point no domain name space is available for inspection, let alone inclusion in to the HTTP Basic Autentication header.

I testet with Thunderbird with SOGo Connector, but all Add-Ons which use the passwort management of Thunderbird will probably work this way.

Thunderbird should probably understand that a URL for HTTP Basic Authentication could be something other than the generic 'http://kolab.example.org', and could instead be 'http://username@kolab.example.org' (or even 'http://username:password@kolab.example.org', but that'll likely cut too deep in to its password management).

This seems to be too workaroundish. I vote against it.