[Ietf-caldav] authorization identity

[Arnaud Quillaud]

I was talking about the "sudo" user.

Thanks.

Arnaud

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:cyrus at daboo.name] 
> Envoyé : samedi 7 juillet 2007 16:47
> À : Arnaud Quillaud; ietf-caldav at osafoundation.org
> Objet : Re: [Ietf-caldav] authorization identity
> 
> 
> 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
> 
>