Principals, Calendar Users and so on
An attempt to explain the relationship between all the user and group related concepts we are dealing with.
Itip Calendar users
In itip calendar users are identified in attendee properties as a uri, usuually of the form "mailto:auser@someplace.org".
There has been some discussion about having a calendaring specific uri, e.g. "schedule:auser@someplace.org" but this has me with some resistance.
The calendar user address is known externally and can be provided to other people as a way of sending invitations or publishing event information. The address can be used to add the user as a recipient or as an attendee.
Ical attendee parameters
There are a number of parameters attached to an attendee property. These are mostly informational and intended to enhance the end-user experience. For example, "cn" provides a printable name, "dir" provide a uri allowing lookup of further information. An exception is the cutype parameter which determines the type of attendee, e.g. individual or group.
Bedework users
A bedework user is generally specified as a simple account name, e.g. testuser01, avery, tom, deacon, harry or whatever. These will be the accounts used in the organization running the calendar and authenticated using that organizations authentication service - e.g. ldap. There are associated user entries in the bedework database and aces in acls will refer to these accounts to grant or deny access.
Bedework groups
These generally look the same as user accounts but have associated information defining them as a group. Once again, other than for admin groups, they will usually be defined by some directory service like ldap external to bedework. Plugin classes allow bedework to query the directory to determine group membership.
Principals and principal hierarchies
WebDAV (and therefore CalDAV) require an organization to support some form of searchable principal hierarchy. This need not be part of the bedework system; in fact it is probably more appropriate that it be part of the organizations infrastructure. This hierarchy and the user and group nodes support properties that allow querying applications to locate services for the prncipal.
For example, given the calendar user address, "maito:jim@mysite.org" we should be able to search the principal hierarchy to locate the associated entry and from the propreties determine where the calendar for that user is located.
The principal properties of particular interest are:
- CALDAV:calendar-home-set - Identifies the URLs of any WebDAV collections that contain calendar collections owned by the associated principal resource.
- CALDAV:schedule-inbox-URL - Identify the URL of the scheduling Inbox collection owned by the associated principal resource.
- CALDAV:schedule-outbox-URL- Identify the URL of the scheduling Outbox collection owned by the associated principal resource.
- CALDAV:calendar-user-address-set - Identify the calendar addresses of the associated principal resource.
This last property can be used to determine the calendar urls associated with a calendar user address. There's an example in section 8.2.4. of caldav scheduling.
Accounts, calendar user addresses, principals.
So we have all three - bedework provides some help in converting from one to the other. As yet it's certainly probable there are problems in this area.
The first conversion is between a calendar user address and an internal account. At the moment this is being done using plain old pattern matching.
This also involves the calendar system id which is set at configuration time. This system id is also used in uid generation and looks something like
calenadar-name@cal.mysite.org
Given a user account, e.g. testuser01 we convert it to a calendar user address by prepending mailto: and appending the portion of the system id from the @ to the end. In this case it would give us
mailto:testuser01@cal.mysite.org
We reverse this process to see if we have a potential local calendar user. Given mailto:testuser01@cal.mysite.org we would check to see if the @ and following text match the corresponding part of the system id.
If so we assume the part following the mailto: and before the @, i.e. testuser01 is a potential user. We call a user validation entry to check that (by default in the quickstart always returns true.)
Rather than the above, we should probably be searching the principal hierarchy.
WebDAV list discussion
As can be seen from the following - all is not fully defined...
From: Cyrus Daboo <cyrus@daboo.name> Date: Tue, 30 Jan 2007 16:37:44 -0700 To: WebDAV <w3c-dist-auth@w3.org> Message-ID: <1FD8D7C463595B85BBDC7394@ninevah.local> Hi, What is the right way on a WebDAV server supporting ACL for a client to determine the principal resource for the currently authenticated user? Right now the only technique I know of is to do: 1) PROPFIND on a resource to get DAV:principal-collection-set 2) Iterate over each DAV:href in the set and do a DAV:principal-match report for DAV:self. The problem with that is that it not only returns the current user's principal, but any group principal that one is a member of. So how would you know from those which was the actual user principal? i.e. this approach is not 100% reliable. If there really isn't a way to reliably do this now, I would propose the following: define a new DAV:self-principal-resource (or just DAV:self) property that is available on any resource supporting ACL and which contains a single DAV:href pointing to the principal resource for the currently authorized user (or is empty if anonymous). Note that in CalDAV it is important for a client to know the principal resource, as there are properties on the principal resource that are required to find a users calendars, inbox, outbox etc -- Cyrus Daboo
From: Julian Reschke <julian.reschke@gmx.de> Date: Wed, 31 Jan 2007 19:55:08 +0100 Message-ID: <45C0E60C.4080301@gmx.de> To: Cyrus Daboo <cyrus@daboo.name> CC: WebDAV <w3c-dist-auth@w3.org>, "'acl@webdav.org'" <acl@webdav.org> Hi Cyrus, (ccing the ACL mailing list). Cyrus Daboo schrieb: > > Hi, > What is the right way on a WebDAV server supporting ACL for a client to > determine the principal resource for the currently authenticated user? As far as I can recall, in general there simply isn't a single principal resource. > Right now the only technique I know of is to do: > > 1) PROPFIND on a resource to get DAV:principal-collection-set > 2) Iterate over each DAV:href in the set and do a DAV:principal-match > report for DAV:self. Yep. > The problem with that is that it not only returns the current user's > principal, but any group principal that one is a member of. So how would > you know from those which was the actual user principal? i.e. this > approach is not 100% reliable. Well, you can easily filter out groups, but in the end you may still end up with more than one resource. > If there really isn't a way to reliably do this now, I would propose the > following: define a new DAV:self-principal-resource (or just DAV:self) > property that is available on any resource supporting ACL and which > contains a single DAV:href pointing to the principal resource for the > currently authorized user (or is empty if anonymous). I think the spec would have defined exactly that would there have been a consensus that this kind of definition always is meaningful. > Note that in CalDAV it is important for a client to know the principal > resource, as there are properties on the principal resource that are > required to find a users calendars, inbox, outbox etc Best regards, Julian
From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net> Date: Thu, 1 Feb 2007 16:21:55 -0800 Cc: Cyrus Daboo <cyrus@daboo.name>, "'acl@webdav.org'" <acl@webdav.org>, WebDAV <w3c-dist-auth@w3.org> Message-Id: <48FE21A9-690E-49CA-8DB5-8086B5471CAB@wsanchez.net> To: Julian Reschke <julian.reschke@gmx.de> On Jan 31, 2007, at 10:55 AM, Julian Reschke wrote: > Cyrus Daboo schrieb: > >> The problem with that is that it not only returns the current >> user's principal, but any group principal that one is a member of. >> So how would you know from those which was the actual user >> principal? i.e. this approach is not 100% reliable. > > Well, you can easily filter out groups, but in the end you may still > end up with more than one resource. Filtering out groups is not correct. Nothing says that a user's principal can't also be a group; a user can have members. >> If there really isn't a way to reliably do this now, I would >> propose the following: define a new DAV:self-principal-resource (or >> just DAV:self) property that is available on any resource >> supporting ACL and which contains a single DAV:href pointing to the >> principal resource for the currently authorized user (or is empty >> if anonymous). > > I think the spec would have defined exactly that would there have > been a consensus that this kind of definition always is meaningful. So would it be reasonable to define this in an extention where we can define it meaningfully? Some background: In the context of CalDAV, some of us are considering the value of having one URL you can give to any user with which a CalDAV client can be configured to find your calendar server and take it from there. This requires that at least one (ideally any) CalDAV resource on the server be able to tell the connecting user where their principal resource is. The reason for that it that the principal has some important information that a client needs to bootstrap itself. In particular, it defined a property which tells the client where the user's home collection is, and another listing the valid calendar user addresses (needed to know who "I" am in the context of iTIP messages). What we are doing at Apple right now is we give each user the URL to their principal. This is no big deal if you can rely on a directory system to find that, but even then, it's a bit of an administrative bother. We're defining a string template from which you can compute this URL from other data about the user in the directory (eg. username). It's putting the directory in a position of needing to know something about the URL schema of the calendar server. Much easier would be to give all users the same URL (eg. the root resource) and give the client a way to locate the principal themselves. -wsv
From: Julian Reschke <julian.reschke@gmx.de> Date: Fri, 02 Feb 2007 09:40:18 +0100 Message-ID: <45C2F8F2.3080208@gmx.de> To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net> CC: Cyrus Daboo <cyrus@daboo.name>, "'acl@webdav.org'" <acl@webdav.org>, WebDAV <w3c-dist-auth@w3.org> Wilfredo Sánchez Vega schrieb: > So would it be reasonable to define this in an extention where we can > define it meaningfully? I would think so. After all, the problem is not defining how to get the URL (live property or report), but to exactly define what it is (because RFC3744 doesn't do it). If we can do that, I wouldn't be opposed to add it to RFC3744bis. > ... Best regards, Julian
