[Ietf-caldav] authorization identity

[Cyrus Daboo]

Hi Arnaud,

--On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud 
<Arnaud.Quillaud at Sun.COM> wrote:

> For connection oriented protocols, SASL defines the notion of
> authorization identity
> (http://tools.ietf.org/html/rfc4422#section-3.4.1).  This allows to
> authenticate as one user and then "switch identity" to act as another
> user for all following operations (of course assuming that the
> authenticated user has the right to act on behalf of the other user).
>
> HTTP and HTTP Basic authentication (http://tools.ietf.org/html/rfc2617)
> which is more or less the only auth mechanism supported by CalDAV do not
> seem to include such functionality.
>
> Is the functionality actually defined somewhere else or is it missing
> from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using proprietary
> mechanism (e.g. simple http header) to achieve the same result ?

It is missing. In the Apple CalendarServer we have a private header that 
does this. We maintain a special list of "sudo" users - those are users who 
can authenticate using HTTP but then authorize as someone else by including 
the special header. I think any revisions to or new mechanisms for HTTP 
auth should include an authorization identity facility.

BTW Do you want to use this facility to support calendar user proxying - 
i.e. one user acting on behalf of another? If so, there is an alternative 
approach to that that we also implemented and which has been presented to 
Calconnect to move forward with standarizing. Our approach for that is to 
use ACLs - basically the server has two group principals per "primary" 
principal. Members of those groups are proxy users for the corresponding 
primary principal. The server automatically provisions privileges on each 
user's account such that these proxy groups have the appropriate privileges 
(one group only has read access, the other group additionally has write and 
scheduling access). This approach allows a calendar client to control proxy 
user access by simply adding/removing users on the relevant proxy group 
principals.

There are several benefits to this over the authorization identity approach 
- not least is the ability to disable access on specific resources via 
ACLs. i.e. there are times when you don't want a proxy to see events - ones 
that might relate directly to them or others etc. This approach allows 
that, whereas an authorization identity will not.

Calconnect is working on a more generalized concept based on this, that 
would allow definition of arbitrary "roles" (two of which map to the proxy 
groups we have). Hopefully we will be submitting something to the IETF soon 
for standardization.



-- 
Cyrus Daboo