Re: svn auth

On Fri, Aug 24, 2001 at 05:40:09PM +0200, Sander Striker wrote:
>...
> 1. Will the action specific access control be maintained (as
> currently described in the design doc)?

We can easily limit on a per-HTTP method basis. For example, we require an
authenticated, valid user for the MKACTIVITY, CHECKOUT, and PUT methods.
Without those, a person cannot commit a change.

Of course... that isn't wrapped up as "nice" SVN concepts, which is where a
mod_auth_svn might come into play.

> This is a very usefull feature, to say the least. I'm referring
> to the example idea of a back-end implementation of svn_authorize().
> There roles are mapped to users and repository paths.

I think you should learn more about the existing Apache authentication and
determine where/how that fails what you have in mind. It would /not/ be good
for SVN to go and develop a complete, secondary auth system when the front
line of our server is Apache. Integrating the auth system tightly with
Apache will be the best thing for admins out there. Maintaining multiple
auth systems is one of the bigger problems for an admin.

CVS is just such a beast with its separate CVSROOT/passwd crap. Through
Apache's authentication hooks, we can integrate with an admin's PAM
database, or an LDAP server of users, or Kerberos or NTLM or whatever.

>...
> I understand that the svn_security file idea is outdated, but
> something anologue to that would surely be implemented(?), keeping
> these points valid.

I don't recall the design of the svn_security file, nor will I research. It
is dead and gone. :-) Again, I'd recommend learning the current system and
bringing up your ideas w.r.t to that.

> 2. Are the supported auth methods going to be configurable (ie. can
> an admin switch the weaker ones off?

Absolutely. Apache allows you to state what auth methods are acceptable for
a given location in the tree.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org