LDAP Struggle

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: LDAP Struggle

[Niclas Hedhman <ni...@hedhman.org>]

On 9/20/07, Emmanuel Lecharny <el...@gmail.com> wrote:

> 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.

Ah! Well, I must say that it is not a day too soon. :o)

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

I'll take a look... but that is not a promise that I'll implement it ;o)

Cheers
Niclas

Re: LDAP Struggle

[Emmanuel Lecharny <el...@gmail.com>]

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 <ni...@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