[Kroupware] Kolab IMAP -> iCal

[Jason A. Pattie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GOAL:  Make public data accessible to the public, but the public data is
based on private data.

Solution 1: Set up a privileged user to separate public data from
private and post it to the web server

Solution 2: Since we're setting up a "proxy" anyway to enable
non-Kroupware (but iCal) clients to work with the Kolab server, that
same "proxy" could write public VFB/iCal files/data to the web server
- --------
Pros:
Solution 1 - realtime updates; data is always current

Solution 2 - does not require privileged user to have READ access to
everyone's data; the individual user's credentials are used to access
their own data, then written to non-privileged location

Cons:
Solution 1 - requires a privileged user

Solution 2 - not updated by Kroupware clients (may be added in future);
not going to be current if Kroupware clients make changes

Conclusion:
The privileged user approach is more efficient and better if it can be
done securely.

Diego Rivera wrote:
> 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.

Should we maybe differentiate based on whether they access the server
using HTTP or HTTPS?  (See below)

> 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.

However, we are thinking of clients that do not have Kroupware
capabilities (Mozilla, Evolution, Apple, etc.) that can use HTTP(S) to
pull an iCal file as well as public information from the web server (we
would like to accomplish both).  So in one instance, when
accessing/updating private information, you need the user to
authenticate with their credentials, but on the other hand you don't
need authentication when accessing public data.

> 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!


- --
Jason A. Pattie
pattieja at xperienceinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE+18z2uYsUrHkpYtARAvY6AJ9fKEAN/0IZ1K72Xtj8qHCKVI1KMACfX+89
D7kubxODAhs8KBlsdyDZ6+0=
=WUA8
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.