My whole point was that Subversion doesn't force you to use a built-in
security scheme.
YOU are free to choose the system YOU want for passwords. We use LDAP and
Apache. You can use ssh keys, wallet, kerberos, or simply store the
information in a text auth-password file and use plain old "svn". Exactly
how you do your security is up to the site.
On Tue, Sep 1, 2009 at 10:14 AM, <kmradke_at_rockwellcollins.com> wrote:
>
> Nico Kadel-Garcia <nkadel_at_gmail.com> wrote on 08/31/2009 06:57:30 PM:
>
> > 2009/8/31 David Weintraub <qazwart_at_gmail.com>:
> > > Subversion doesn't have its own native security. This is actually a
> better
> > > way because it allows you to use external security regimens.
> > >
> > > For example, we use LDAP and connect to our Active Server via Apache.
> Now, I
> > > don't have to worry about settiing up users independently. If a user is
> in
> > > the Windows server's engineering group, they automatically have access
> to
> > > Subversion without me doing anything. Once they leave, they have no
> more
> > > access.
> > >
> > > Even better, their Subversion password is the same as their Windows
> > > password. No more forgetting their password.
> > >
> > > If I use ssh+svn://, the operating system handles logging in and out.
> My
> > > name and password is the same as my Unix account.
> >
> > What? No-no-no-no-no. This is used by some, but the far safer and more
> > useful way to do is to designate an svn user, who's
> > $HOME/.ssh/authorized_keys file This relies on SSH keys, not
> > passwords, which allows single-sign-on style user access by having an
> > ssh-agent (or a Gnome or KDE "wallet", which is out of band of
> > Subversion's key storage).
>
> > No user passwords. None. Nyet. Nil. Nein. Nada. A user selected
> > password is normally used to unlock the relevant SSH key, and a Gnome
> > or KDE wallet can manage that. And this way, the repository URL's look
> > ile 'svn+ssh://svn@reposerver/var/lib/svn/repository', or a similar
> > structure. This allows user login to that server to be quite distinct
> > and even unnecessary. This is the approach that Sourceforge uses, for
> > example. The public SSH key in is set to designate the relevant
> > Subversion user based on which key is used. It's a very handy
> > approach, and avoids the security issues that I tend to rant about, at
> > the cost of some setup time.
>
> This setup is a pain for both the user and the administrator. Additional
> steps must be performed by each before work can begin.
> (And ssh keys are really no better than a password, you are just
> forcing the user to have different piece of secret information.)
>
> Why not use something like kerberos? Windows will transparently
> checkout a ticket. No password needed and no additional setup needed
> by either the user or the administrator for new users. Granted, this
> only works well in a corporate environment, but it is a very big win
> when dealing with less technical users...
>
> The beauty of Subversion is that it lets YOU choose the
> appropriate authentication method for your environment.
>
> Kevin R.
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389877
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 20:47:52 CEST