User identification is Authentication. Determining if that user can do
whatever they want is Authorization. The HTTP spec tells you how you use
HTTP to require authentication. Basic, NTLM, Kerberos, or whatever else
you can come up would work for authentication. The entire process is
usually kept secure by using a secure transport like SSL.
Now having said that, the source of pontential users could certainly
come from an LDAP, or Active Directory store. Groups could even come
from such a source as well.
Bill
-----Original Message-----
From: roger day [mailto:roger@nenuphar.freeserve.co.uk]
Sent: Saturday, August 25, 2001 2:16 PM
To: Bill Tutt; 'C. Scott Ananian'
Cc: dev@subversion.tigris.org
Subject: Re: SVN and Authorization
How do you -identify- somebody (and hence their privileges) in a
cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is
complex.
----- Original Message -----
From: "Bill Tutt" <rassilon@lyra.org>
To: "'C. Scott Ananian'" <cananian@lesser-magoo.lcs.mit.edu>
Cc: <dev@subversion.tigris.org>
Sent: Saturday, August 25, 2001 02:32
Subject: SVN and Authorization
>
>
> From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
>
> > On Sat, 25 Aug 2001, Sander Striker wrote:
>
> > > The case where apache isn't involved. We need a way to let the
> repos
> > > handle if a user X is allowed Y on path Z. The berkeley argument
> > > won't hold, since if we get around to implementing the sql
backend,
> > > writing to the repos isn't so easy as it is now with berkeley db.
> > > This can be done through hooks. The read/write sentinels seems a
> > > pretty efficient solution. Then again, discussion is always ok :)
>
> > I read the berkeley db argument as, "The filesystem is responsible
> > for authentication and enforcing access controls for local
> > repositories". The initial file system implementation, built on
> > Berkeley DB, seems to be a 'permissions-free' file system. As you
> > point out, implementing the filesystem on top of a "real" DB would
> > enforce whatever authentication/access control mechanisms the DB
> > enforced. I'm still hoping for a plain-text unixy filesystem
> > implementation at some point; this impl would extends unix
> > authentication/etc to SVN.
>
> Ick. You really don't want to use a unixy file system approach to
> authorization issues. Security models have gotten so much better since
> then.
>
> Here's a possible security model for SVN:
>
> There are the following access levels:
> * Read: The level ViewSVN would need. Displays file histories, and
> actual contents, but you can't actually commit any changes.
> * Write: You can commit changes, and stuff.
> * Admin: You can do anything. (user management, etc...)
>
> An SVN ACL would contain the following info:
> * Access level
> * User/Group this Access Level applies to, can apply to everyone
> (except admin).
> * Hosts this access level is allowed for. (Standard IP wildcarding
> stuff
> here)
> * Path of the repository that this access applies to. E.g. a path of
'/'
> would mean apply to the whole repository. While a path of
'/blah/blah2'
> would apply to all subdirectories of blah2.
>
> A DACL (deny ACL) would contain the exact same information, except it
> would prevent the associated user/group from obtaining the requested
> access level on a given path.
>
> Decent security models allow resources to be accessed by more than one
> group, and allow the use of DACLs to handle group overlap problem
> cases. Unix filesystems don't even come close to allowing that kind of
> flexibility.
>
> Note: The above doesn't take any kind of consideration for the current
> state of the SVN file system layer, it's just an idea. :)
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006