Handling of private/confidential groupware objects

[Martin Konold]

Am Donnerstag, 12. Januar 2006 09:22 schrieb Joon Radley:

Hi Joon,

> > This seems to be known in the OL community.

> depends on the permissions the user has on the mailbox, so this is actually
> a configuration problem. In this case, the administrator gave users too
> many permissions on the Security tab of the shared account's property
> sheets in Active Directory User and Computers."

I tested the issue with a real exchange server and the "hidden" data indeed 
traveled on the wire while OL was only showing  part of it. (E.g. OL does not 
show the subject or the body)

My interpretation of the above statement about "too many permissions" is that 
if any user access permissions to the folder he/she can access all data 
provided he/she uses a tools to grab the data from the wire.

> > We would then use copyright in order to prevent other clients
> > to use our key ;-)
>
> This fails on a number of levels:

Of course I know that this would fail. This is actually the reason why I added 
a smiley at the end of the sentence. From a pure technical point of view it 
would though be as good/bad like the imho broken MS implementation. IMHO the 
MS implementation provides a false feeling of security to the users of 
exchange by using a "security by obscurity" approach.

> C) This also has bearing on your "hidden private subfolder". Private
> objects are not totally hidden. The objects are only partially displayed,
> e.g. the start and end times, so that the shared user can see when the main
> user has an appointment, but cannot see details about the appointment. The
> important thing is that the server only provides certain parts of the
> information.

The solution to C is imho as follows and imho solves all this issues in a 
consistent and reliable manner.

1st case - the event is not marked private 

1a) writing to Kolab
--> store event in the calendar folder in OL 

--> store event in the calendar folder on the server

1b) reading from Kolab
--> read the event from the imap server and store it in the OL folder 

This is the currently implemented semantic

2. case - the event is marked private

--> store it in the calendar folder in OL using the "private" property 
(already current situation)

2a) writing to Kolab
--> store the not to be hidden data in the calendar folder on the server 
including the private flag (see XML entity) e.g. INBOX/calendar

--> store the full data(*) of the event in the "hidden"(**) calendar e.g. 
INBOX/hidden/calendar

(*) this includes the unique calendar id which allows to bidirectionally 
identify the companion in the visible calendar folder

(**) this hidden hierarchy is _only_ readable and accessable to the owner of 
the mailbox using IMAP ACLs. We must make sure that it is impossible for 
others which have access to shared folders can manipulate the ACLs of the 
hidden hierarchy.

2b) reading from Kolab
--> read the event from the calendar folder (e.g. INBOX/calendar) from the 
Kolab server and store it in the OL folder. When detecting that the private 
flag is set on an entry the connector component MUST look up the _same_ 
calendar uid in the hidden hierarchy folder (e.g. hidden/calendar) simply 
using the imap folder name of the calendar and prefixing it with "hidden/".

--> store the private event read from the hidden folder to the "normal" OL 
folder. The event stored in the OL folder contains all data including the 
private flag.

The BIG advantage of my proposal is that both Kolab freebusy and Outlook 
remiders keep working as expected WITHOUT any code changes! 

Last but not least we keep working correctly with PDAs (Palm and Pocket PC).

In short: 

We use the boolean private flag to decide in which imap folder to store the 
event. (e.g. INBOX/foo/bar and hidden/foo/bar). The hidden folder hierarchy 
is always only accessable to the owner of the mailbox (no sharing). When 
reading events from the Kolab server it must be checked if the private flag 
is set. In case it is set the full data must be obtained from the hidden 
folder hierarchy. 

From modifications are limited to the connector and from the point of view of 
OL, PDAs or the end user everything works as expected.

I hope that the concept is now better understandable. 

Please don't hesitate to aks further questions.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker