Re: SVN and LDAP

Ok, I quickly tried this again, and I get restricted behavior if
I try and navigate using either the TortoiseSVN repo-browser or
Internet Explorer, but if I use TortoiseSVN to checkout the
top level folder, the subdir restrictions are not used:

<Location /kmr_test>
  Require group CN=In_This_One,...
</Location>

<Location /kmr_test/private>
  Require group CN=Not_For_Me,...
</Location>

If I "checkout" /kmr_test, I get the contents of private, even
without being in the group.

Am I missing something?

Apache 2.2.8 (So I'm actually using require ldap-group), Subversion 1.4.6.

Kevin R.

"Adam Hubscher" <offbeatadam_at_gmail.com> wrote on 04/18/2008 12:00:48 PM:
> 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