Handling of private/confidential groupware objects
Martin Konold
martin.konold at erfrakon.de
Fri Jan 13 03:03:09 CET 2006
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
More information about the format
mailing list