Thanks for the kind words Adam. I hope I've saved you some pain :-)
We have a similar situation where we use LDAP (well, AD fronted by LDAP)
to manage our users and groups. Redefining all of that "just" for SVN
would never fly. Integrating through mod_auth_ldap makes it all easy and
if I can automate the Apache rule generation (Kevin: Thanks for the
'apachectl graceful' reminder!) then it more or less just runs itself for
the common case.
I want to look into Kevin's "top-level checkout" issue Monday and see if I
can reproduce it in our environment. I'm pretty sure I solved that since
it is an obvious loophole but he's clearly experiencing it so I need to go
back to my notes and test system to figure it out.
> Oops... I sent this to only one person. Forgot to hit reply to all. :)
>
> James, I thank you. You're a gentleman and a scholar. That was a
> fantastic description of possibly the best way I could have considered
> doing it. It hadn't dawned on me to use Apache's request based
> security rather than attempting a patchwork authz based solution -
> this provides a much more granular approach to security. In an
> environment where compliance, SOX, PCI, et al... is becoming very
> prominent, this will ensure that the appropriate permissions are
> separated between contractors and full time employees appropriately.
>
> In regards to the performance question, there is a bell curve that you
> have to look at when you are deploying this in a situation that would
> truly warrant LDAP. For example...
>
> In my department, we have ~200 users that will use SVN exclusively as
> part of their job on a daily basis. Further, there are ~400 or more
> users that would use it for other tasks on a semi-frequent basis.
>
> Controlling this large group of SVN users is daunting. The time that
> it would take to appropriately administer and generate the SVN ACLs
> for these various locations would be nearing that 40-hour work day
> that we all strive for. With LDAP, this administration overhead and
> time is rendered near moot as all we have to do is maintain an LDAP
> group - the permissions are permanent based on group.
>
> So, if you look at it this way - if the authentication performance is
> based solely on the library itself and maintenance is not an issue -
> SVN local authentication is going to be king. There is nothing that
> hinders it. However, if you have a large group of people, and you have
> a directory infrastructure (active directory, openLDAP, etc),
> leveraging this will offset the overall performance loss of having to
> traverse the network.
>
> In such an environment, the LDAP performance is seen with everything
> else on a daily basis, so the overall login time is practically
> meaningless. We already use LDAP on the apache login itself, we were
> just using SVN ACLs prior and were looking for a more manageable
> solution.
>
>
> On Fri, Apr 18, 2008 at 10:22 AM, <kmradke_at_rockwellcollins.com> wrote:
>> "James CE Johnson" <jcej_at_tragus.org> wrote on 04/18/2008 10:23:15 AM:
>>
>>
>> > > On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson <jcej_at_tragus.org>
>> > > wrote:
>> > >> Hey Adam,
>> > >>
>> > >> This got a bit wordy as I was writing it up so I dumped it on my
>> > >> too-often
>> > >> neglected blog:
>> > >>
>> http://pteropus.blogspot.com/2008/04/securing-subversion-via-ldap.html
>> > >
>> > > Wow, that is detailed! Thanks for the post - I'm hoping to move our
>> > > SVN authentication to LDAP this year and it would be terrific if I
>> > > could move the authorization into LDAP as well. It means less work
>> for
>> > > me - I'm the SVN admin but someone else does LDAP :)
>> >
>> > Same here. In fact, I'm working with our group to figure out exactly
>> how
>> > we're going to manage (and hopefully delegate) the LDAP side of
>> things.
>> >
>> > > 2 questions:
>> > >
>> > > 1) How is performance, as compared to using SVN's built-in Authz
>> > > stuff? Faster? Slower? I know a lot of path-based checks can cause
>> > > some operations to be slower.
>> >
>> > I haven't tested the two against one another. With LDAP's caching we
>> can
>> > take the lookup and network hits pretty much out of the picture. My
>> gut
>> > would say that the built-in stuff is probably faster *but* from past
>> > experience I know that it inspects its auth file with every request
>> --
>> I'm
>> > sure it doesn't read the file every time but it at least has to do a
>> > timestamp check. LDAP integration is a fundamental requirement for
>> us,
>> > though, so the built-in was never an option.
>> >
>> > > 2) If you have a change to path access (which groups can access
>> which
>> > > paths), doesn't this require a restart of Apache?
>> >
>> > I believe so. That has always been my pattern of action. I will test
>> any
>> > changes in my dev zone then replicate that in production and bounce
>> the
>> > server off-hours. Now that you've made me think about it I'll have to
>> go
>> > test that again :-)
>>
>> httpd -k graceful
>>
>> or
>>
>> apachectl graceful
>>
>>
>> is your friend...
>>
>> Kevin R.
>>
>
>
>
> --
>>>~OffbeatAdam~<<
> "I'm not going there to die, I'm going to find out if I'm really
> alive." - Spike, Cowboy Bebop
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-18 20:40:45 CEST