top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

SVN: AuthType Basic (with ext LDAP)

+1 vote

There is a simple setup for svn users authentication on the server using LDAP.

 DAV svn
 SVNListParentPath on
 SVNParentPath /path_to_data
 SVNListParentPath on
 AuthzSVNAccessFile /path_to_accessfile/accfile

 AuthzLDAPAuthoritative off
 AuthType Basic
 AuthBasicProvider ldap
 AuthName "your login pls"
 AuthLDAPBindDN "blah-blah"
 AuthLDAPBindPassword "somepass"
 AuthLDAPURL "ldap://URL+DC?sub?(objectClass=*)"
 AuthzForceUsernameCase Lower
 Require valid-user

 CheckSpelling On

What I noticed is that svn server making a request for each svn URI or operation, which neither LDAP server likes nor users that could be waiting for their turn to be authenticated and see delays in svn server

Could somebody point me where the problem is? I'd expect only one authentication request from the server when user presents himself first time (or after cache expires).

posted Oct 18, 2013 by Garima Jain

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

This is a feature. It allows you to use Apache authentication setups that are path based like mod_authz_svn is. In your case (and most users case) the only authentication handler that cares about the path is mod_authz_svn, in which case you can use the mod_dav_svn configuration directive "SVNPathAuthz
short_circuit" which will prevent subrequests from being generated for additional paths that a request touches other than the path in the request URI and instead simply ask mod_authz_svn to process the path directly. This will speed up your server by quite a bit since subrequests are slow as well as resolving your problem with LDAP.

answer Oct 18, 2013 by Satish Mishra
When short_circuit is enabled, then LDAP requests are not recorded any  more in the debug log (except for initial request), so that what I was looking for. Great.

But there are still checks (or maybe this is just info log) against  access-file for each path in repository. Is it something expected or enabled somewhere by default?

[Fri Oct 18 15:35:52 2013] [info] [client] Access granted: 'user1' REPORT /trunk/very_long_path/Data.manifest
[Fri Oct 18 15:35:52 2013] [debug] subversion/mod_authz_svn/mod_authz_svn.c(195): [client] Path to authz file is /path_to_access_file/svn_acc

I mean if a user has access to a repository, why checking all paths under? Or its just info log about mod_authz_svn processing path directly, as you said?
The authz access file is only read once per connection.

But the checks will be run for each path accessed by the request. Some of the requests over HTTP actually access multiple paths in the repository. For instance a REPORT request might be doing what's referred to as a bulk update, in which case it's asking for details on all the paths under a given path. The update REPORT in this case will include file content for paths under the path. Only the top level path will be in the URI. If you want to disallow access to some paths under that root path of the request it is necessary to check all the paths. Some other operations like COPY and MOVE also touch paths other than the one in the URI for the request since the action requires two paths.

So what you're seeing is perfectly normal operation for the short_circuit configuration. You can entirely disable the additional checks mentioned above by setting "SVNPathAuthz off". However, I would not recommend that as it will make some authz rules ineffective. The whole created by this in the update report case can be closed by also setting "SVNAllowBulkUpdate off" but that doesn't help the COPY or MOVE cases. So in general, there's really not a great reason to use the off setting.
Another option is caching the LDAP requests to avoid beating up the LDAP server(s).

# Allocate maximum of 256K RAM for cache
LDAPSharedCacheSize 262144

# Save 1K cache entries for successful search/binds
LDAPCacheEntries 1024

# Keep entries in cache for 8 hours for successful search/binds
LDAPCacheTTL 28800

# Save 1K cache entries for successful compare operations
LDAPOpCacheEntries 1024

# Keep entries in cache for 8 hours for successful compare operations
LDAPOpCacheTTL 28800
Similar Questions
+3 votes

We have integrated apache web server with our internal LDAP and we have requirement to provision role based access to the folders in the docroot. We have earlier used SVN and we were using AuthzSVNAccessFile to meet this requirement. Contents of the file will look like this.

users = usera
admins = usera, userb
users = r

admins= r

Now we are looking for something similar with the apache directives, is it possible? if not, can you please give us an alternate?

I have tried "Require ", it doesn’t solve our requirement.

+2 votes

I have installed Bugzilla 4.4 on Apache. I have configured it for LDAP authentication. I have some users on LDAP and I wish to allow all of them to be able to file a bug on Bugzilla.

However, it appears that I still need to create all these users in bugzilla. Instead of creating 100 users one by one - is there a way I could insert records in some table OR any configuration by which the user is automatically created?

What is the best way to configure in this case?

0 votes

I know that in version 3.3.9 Mongodb supports LDAP on windows. So I wanted to know whether it will be available for Community Edition or it remains for the Enterprise Edition only?

+6 votes

I am trying to configure PAM to connect to OpenDJ LDAP server, however seem tricky , I configured via system-config-authentication tool and sssd gets restarted,

Please let me know a simple way to connect to SSL based LDAP server to authenticate users created in LDAP server.

0 votes

Question about the http authentication when using the subversion api 1.8.13.

For example using the svn_client_list3' function: Everytime this function is called the first http request does not contain any Authorization header which leads to a 401 Authorization Required' response.

In my opinion this leads to an unnecessary delay when the function is called multiple times and the same credentials could be used.

When calling this function the svn_client_ctx_t contains an svn_auth_baton_t with set default username and default password parameters.

Now to my actual question:

Can this behaviour somehow be changed or is it just designed to work this way? I also know that the version I'm using is not the newest one so if you think an upgrade to a newer version could lead to some performance improvement please let me know.