ADD_ACL/DEL_ACL (was Re: Access Authorization)

"Christopher J. McRae" <Christopher.McRae@library.ucsf.edu>
Message-id: <199309281636.AA16758@library.ucsf.edu>
To: www-talk@library.ucsf.edu
Subject: ADD_ACL/DEL_ACL (was Re: Access Authorization)
Date: Tue, 28 Sep 1993 09:42:21 PDT
From: "Christopher J. McRae" <Christopher.McRae@library.ucsf.edu>

Now that the other discussion has died down...

Wayne Allen writes [edited quotation]:
> Now, about access control....authentication is a somewhat
> separate issue from authorization.
> For example, HTTP (the protocol) needs to support a variety of
> authentication mechanisms, but the authorization process need not
> involve the protocol definition at all.
> 

  Yes, authentication and authorization *are* most properly dealt with as
separate issues.  HOWEVER, I disagree with the assertion that there are
no protocol issues involved in the authorization process.

  In particular, I am concerned about how access priveleges are to be
administered on the server.  As an web administrator, I'd like to be able
to give an author not only the access priveleges to write into some corner
of my web, BUT ALSO the ability to define who else can read/write/search
that corner.  That is, I don't necessarily want to know who the author's
collaborators and audience are.

  One way to implement such priveleges would be via the extant GET/PUT
methods.  One could control GET and/or PUT access for the ACL itself,
The priveleged user could GET the ACL, modify it, and then PUT it.
This design violates the principle of information hiding (encapsulation).
It also opens up potential security holes by allowing the client direct
access to the server's control files.  

  I think it would be better in the long run if the protocol we're to
provide ADD_ACL and DEL_ACL methods.  Something like,
    ADD_ACL acl_handle user_info
    DEL_ACL acl_handle user_info
and perhaps also LS_ACL (or GET_ACL)
    LS_ACL user_info
which lists the priveleges assigned to the specified user.

  This way, the details of ACL implementation would be hidden behind the
abstraction of the method syntax.  Also, a higher level of security could
be required for ADD_ACL/DEL_ACL than for other methods.  

Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143