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
