[Kroupware] Kolab IMAP -> iCal

[Diego Rivera]

On Fri, 2003-05-30 at 13:07, Jason A. Pattie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > I'm going to assume the use of a single "proxy user" that only has read
> > access to the users' Calendar folders is OK'd by everyone.  I'll do this
> > using ACL's so that access can also be denied to particular users.
> 
> But I just found out yesterday how to authenticate using mod_perl to the
> webserver so you can use the username and password credentials to
> authenticate to the IMAP server.

That's where I don't see a need to use a particular user's own
credentials to obtain their free/busy status.  This is an operation that
other users could utilize to retrieve the free/busy information for the
user WITHOUT access to any special set of credentials.

Think of it as the equivalent of a publicly available <user>.vcf that
can be obtained by https://freebusy:xxxx@server.com/freebusy/<user>.vcf
- except it's (potentially) dynamically generated every time.


> Also, if we go the route that the user of the data has to be used, there
> isn't that added administration of setting up the ACL for the "special"
> user, and I would hope, it increases the security of the process
> overall.  You should hopefully only be able to mess with one person's
> data if security is compromised rather than every person's data.


The setting/clearing of the ACL is not a big worry in my mind, since
that can easily be scripted onto a button on a webpage, or a
button/checkbox in the client.

It's using the user's credentials when I don't need to that I want to
avoid.  That's why I think using a proxy user for READ access is a good
idea - it keeps the user's credentials as secret as possible, and gives
anonymous users access to publicly available calendaring information.

I realize this access is already defined to go through the "freebusy"
user's FTP/HTTP access, but think of this as the capability of
supporting "publish free/busy" even when the client can't publish such
info directly.

I see nothing wrong with this approach, whereas requiring a user's
credentials for reading their calendar info might not be the way to go. 
I can just imagine a schmuck or two giving away their credentials when
somebody asks them where they publish their free/busy information!


-- 
===========================================================
* Diego Rivera                                            *
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>='@', <DOT>='.'                            *
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *
===========================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030530/323e3c36/attachment.bin