directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: LDAP Struggle
Date Thu, 20 Sep 2007 08:39:20 GMT
Hi Nicklas,


the fact is that LDAP does not have Join operation. This is why you
have a problem when it comes to manage users x groups matrix, as the
join operation will be delegated to the client.

This is also were we want ADS to be extended with triggers, stored
procedures and views, as any RDBMS. Triggers will help to manage cross
updates (remove a user => automatic removal from groups). Stored
procedure can be used to create join on server, with views to store
the result.

Alex has written wuite a good paper about our vision :
http://directory.apache.org/community%26resources/ldap-renaissance.html

Emmanuel

On 9/20/07, Niclas Hedhman <niclas@hedhman.org> wrote:
>
> Gang,
>
> This is a transcript of an ICQ message to Alex, and he suggested to post it
> here instead...
>
> - o - o -
>
> I would like to revisit my LDAP struggles.
> The starting point is
> http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#reqgroup
>
> I spoke to Mattias Arthursson at Jayway about what this page describes in
> terms of grouping users and allowing access based on those groups. I pointed
> out that when the number of users increases even to a few 100, and the number
> of protection realms grows, the management of this goes completely out of
> hand. 1000 users and 100 differently protected areas == 100,000 mapping
> entries to maintain. I saw that before I started out and wanted to let the
> group contain organizationalRole members, and assign each user one or more
> organizationalRoles, which would in the above example drop the number of
> managed entries to something in the 1000s (a couple of roles per user, often
> only one). He couldn't work out a setup with mod_authnz_ldap to make that
> work.
>
> His conclusion revolved around "there is no JOIN", and that made it failed.
>
> My conclusion is; LDAP is effectively a pure "storage container" with a lookup
> language, without any semantics around associations. Semantics are needed to
> be built into the applications, but since LDAP is so flexible, all 'generic'
> (all the Linux apps claiming LDAP support) apps rely solely on the relatively
> simple lookup language.
>
> Which means that in the case of HTTP, we can perhaps manage with constructs
> of "Require ldap-filter", but then the management of the Access Control List
> itself is back in the Apache HTTP server and not stored in the LDAP.
>
> I find the topic a lot more convoluted than I expected, and I just fail to see
> LDAP becoming popular...
>
> If you have any suggestions on how to solve the N x M explosion of values to
> manage, I am all ears. Otherwise, I think I am hanging up my hat...
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message