[Ietf-caldav] authorization identity

[Tim Hare]

Not to bring my mainframe background into this, but...

Most mainframe security products protect a resource by a profile, to which
users _or_ groups may be granted appropriate access. The advantage of using
groups is that the group can remain in the access list, but someone granted
authority can manage the contents of the group, without being the
owning/controlling administrator of the resource. For example:  I, as system
administrator, may own a set of conference rooms. I can grant scheduling
access to SchedGroup A and SchedGroup B, and allow Manager A and Manager B
to control who within their organization is a member of those groups. This
works well for both parties: if I feel Group B is abusing their privilege
(or for some other reason) I can revoke SchedGroup B's access without
knowing who is in SchedGroupB; the manager can handle staff turnover, or
changes of duties, by determining who he connects to SchedGroupB.

I think the ACL mechanisms work better than allowing 'sudo' switching; and
since things are always occurring in one user's security context, there's no
doubts when debugging or auditing as there would be otherwise. Think of the
case where the sudo doesn't work correctly, some updates in a transaction
get done under the special ID, others under the 'sudo'  ID; this could be
due to program bugs or to multiprocessing environments gone wrong, but it
still adds to the problem of figuring out who actually updated the calendar.


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: ietf-caldav-bounces at osafoundation.org
[mailto:ietf-caldav-bounces at osafoundation.org] On Behalf Of Cyrus Daboo
Sent: Saturday, July 07, 2007 10:47 AM
To: Arnaud Quillaud; ietf-caldav at osafoundation.org
Subject: 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

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav