[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What is the Better Authentication mode: SSPI or LDAP?

From: Shirish Jain <lists_at_getafix.net>
Date: 2007-06-13 12:01:28 CEST

nikhil gupta said the following on 6/13/2007 7:28 PM:
> Hi There,
>
> I'm evaluating which authentication mode to use while setting up SVN
> using Apache. We need to make a cut between SSPI & LDAP. I was
> searching the net for various differences between the two but was not
> able to get much detail.
>
> Could anyone from the group throw some light upon which one is better
> & why?
> What are the various security aspects of the two modes?
if using non-SSPI authentication & SVN win32 command line, user
credentials and password are stored in clear text on the local user
profile. There goes the security. In case of SSPI, u dont have to worry
about these. End user perspective, every time user changes the password,
if do not change the stored password in SVN profile, chances are
accounts will get locked out! Signle-sign-on is true reality with SSPI.
Downside of SSPI only server authentication setup, user cannot generally
use the "--username --password" options on WIN32 command line. Which IMO
is a better security as no more spoofing identity!

There are stability issues of SVN client side SSPI authentication, due
to inherent weaknesses of Neon library(http://www.webdav.org/neon),
which means, you may need to grab patches from Neon Trunk, and
compile/distribute your own SVN clients. (search the mailing list
archives for SSPI/GSSAPI authentication issues)
Hope this helps.

..Shirish

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 13 12:02:37 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.