[Date Prev][Date Next]
RE: Using LDAP to describe permissions
Hmm, as I was writing this out, I worked out the answer to my own
question. I thought I'd still send it out to the mailing list for
posterity, and to help out others.
Allow me to describe my application in greater detail:
My intranet employs a variety of PHP applications like GForge,
MoreGroupWare, phpBB and a few custom solutions. What I'd like to do is
centralize all of these apps' user management systems into a single LDAP
directory. This takes care of all the user description, but I still need
to hack in fine-grained permission control. For example, an app like
MoreGroupWare has a variety of objects, but instead of files or
directories in a file system, they're more like rights that are also
inheritable. Like the right to edit a particular calendar entry would
inherit from the right to access the calendar, which would inherit from
the right to access MoreGroupWare.
This lends itself to a tree structure. In addition to a user tree, the
permissions can be stored in an object tree (remember that in my case
these objects are rights). The key is to maintain two separate trees,
because if one stored permissions to every object in each user record,
it would be quite infeasible.
So that's my answer to my own question of how to do it. LDAP is also
superior to SQL for this because 1) it's a tree, not a table and 2)
performance geared for simple lookups.
So, umm, thanks Howard, and me.
> How should I do it? I could use LDAP to
> store all the account information and put the permissions in a MySQL
Why implement two very different data access methodologies when you
just one? If you understand SQL and you see a way to structure the
data satisfactorily using SQL, and you don't know LDAP, then you're
better off just using SQL. If you're interested in using LDAP, then just
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support