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

Re: Patch for support ldap group in mod authz.

From: Ngo Van Cong <van_cong.ngo_at_int-evry.fr>
Date: 2006-07-07 10:49:22 CEST

Le jeudi 06 juillet 2006 à 13:34 +0200, Lieven Govaerts a écrit :
Hi, i am very happy if this patch will become a part of subversion.
> Hi Cong,
>
> thanks for sharing this patch, it's really interesting. I didn't review it
> thoroughly yet, I just have some high-level questions and remarks:
>
> - What new functionality does this patch provide? If I understand your example
> correctly the function is: 'If this account is part of atleast this LDAP group,
> then allow r/w access for a project/path'. Right?

With mod_auth_ldap it also support the aspect of authorization using
“require group” in file configuration of Apache but the problem is: when
I add new group to ldap server and I want this group is authorized for a
path, I must declare new Location directive and restart apache server.
It is a little hard for admin.
Now I combine the part authorization of mod_auth_ldap with mod_authz
which is make me free when I want a new group in ldap which is
authorized for a path in subversion. I have just declare it in access
file of mod_authz I don't mind what will happen in Apache. Now a group
in ldap is considered as a group normal in access file of mod_authz but
begin with “ldap:” .

> - When do you do the LDAP lookup, for each request? Apache already does an LDAP
> lookup for the authentication part (password validation), so this will have a
> negative performance impact.

In fact, in mod_auth_ldap there are two phases separates: authentication
and authorization. And each phase will also make a connection to ldap
server separate. when i want make a connection to ldap server, i used
the functions of mod_ldap, in fact this function will search in a list
connection for this server and if it find one available, it will lock
this connection and assign for this session.
And another thing is that when a user is authorized, he will be cached
in the system and then if he want to connect to system again he won't
connect to server immediate, first mod_authz will compare him in the
cache, if it don't find this user, in this case it will make connection
to ldap server.

> - Why don't you use the already defined AuthzLDAPURL and AuthzDAPBindDN
> commands?
> - I see you copy large parts of existing code from mod_auth_ldap.c. Why do you
> do that? If you need that functionality, use the existing functions are extract
> common functionality in a new function.

AuthzLDAPBindDN of mod_authz is difference with AuthLDAPBindDN in
mod_auth_ldap because goal of my AuthzLDAPBindDN is for use defaut
group=repos name, so when you want to use default group, you must
declare this directive. Why I want mod_authz to support default group.
Because when I have many repos and each repos is a projet so I must
declare many thing in access file of mod_authz now with default group I
have just create a group name=repos name in ldap server and I don't need
to declare it in file access. In the future, I will support to use
patterm for permission for default group(now permission for default
group is rw)

I think that just one function in mod_auth_ldap can reuse, that is
function for parse a URL but up to now I don't know the way to reuse a
function in another module of apache. And here I want mod_authz run
independent with mod_auth_ldap.

>
> To which branch & reversion of the Subversion code did you make the patch? Do
> you use this already in a test/production system?
>

I have already tested this patch with subversion 1.2.3 and It work well
with group in ldap.

> I'd suggest before adding new functionality to the authn/authz mechanism of
> Subversion we gather requirements and make a design proposal. As far as I'm
> concerned, integration with enterprise architecture for authz is one of the
> weak spots of Subversion and if we want to tackle that (and I really want that)
> we should do it in a structured way.

Another thing that comes to mind is, will this stuff compile if
apr-util is compiled without LDAP support? It's important that we not
add any extra requirements to mod_authz_svn.

I see that in subversion 1.2.3 is already supported apr-util with ldap.
And why this stuff is a extra requirements to mod_authz_svn?

>
> Not to say that your patch isn't welcome, let's use the opportunity as a
> starting point for further discussion.
>
> regards,
>
> Lieven.
>
> Quoting Ngo Van Cong <van_cong.ngo@int-evry.fr>:
>
> > These patches help you to use ldap group in the control access file of
> > the module Authz. if you want to use it, you must declare Directive
> > AuthzSVNLDAPURL this is the path to ldap server.
> > Directive AuthzSVNLDAPBindDN is a bind domain name when you want to
> > use defaut group in ldap server(default group=repos name) for this you
> > must turn on Directive AuthzSVNLDAPEnableDefaultGroup
> >
> > Here is my configuration in apache:
> > AuthzSVNAccessFile /etc/apache2/access.passwd
> > AuthzSVNLDAPURL ldap://localhost/dc=int-evry,dc=fr
> > AuthzSVNLDAPEnableDefaultGroup on
> > AuthzSVNLDAPBindDN ou=group,dc=int-evry,dc=fr
> > AuthzSVNLDAPGroupAttribute memberUid
> >
> > and in the access.passwd
> >
> > [projet1:/home/user1]
> > @user=r
> >
> > [groups]
> > developers = oberger, benoit, admin
> > user = ldap:cn=user,ou=group,dc=int-evry,dc=fr
> > in this case, default group=projet1,for reposistory projet1, in ldap server
> > have permission rw.
> > Regards
> > Cong
> >
> > [SNIPPED VERY LARGE PATCH]
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 10:50:10 2006

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

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