Grouper Developers Forum

[Kathryn Huxtable <>]

For ldappc version 1.0.1 I propose that the main changes be in  
improving performance.

My approach when I was at KU was to create a table in an RDBMS  
containing group/subject tuples and provision the table instead of  
LDAP. Since KU provisions everything in LDAP from RDBMS tables, this  
used KU’s usual provisioning to propagate this data into LDAP and  
keep it synchronized.

Also, I used more memory than the existing code and pulled an entire  
group’s subjects into memory and compared it with the RDBMS table and  
then just made changes. This is a more practical approach to the time/ 
space tradeoff in today’s world where memory is cheap and we want  
fast performance. The ldappc source makes the opposite decision and,  
to the authors’ credit, documents it.

Brown’s approach has been very similar in terms of time/space, but  
they directly query LDAP and make the changes there. There are some  
implementation differences between my KU code and Brown’s, but the  
concepts are congruent and the performance enhancement similar.

My experience at KU was that although querying LDAP had good  
performance for groups, querying for memberships had very poor  
performance. It’s possible that KU’s LDAP was out of cache space for  
the people branch. KU was having some LDAP performance problems at  
the time. Since KU always masters everything in an RDBMS anyway, this  
made the choice of a database table with a separate synchronization  
with LDAP a natural approach.

I’m willing to do this either way, with or without a database table.  
I’ll change the comparison and update code to reflect either my  
approach or, with Brown’s permission, Brown’s approach, depending on  
which one gives the best performance when abstracted and tested  
against some random test data sets.

If I use a database table, my plan is to embed a Derby database by  
default but allow the user to configure any alternate database of  
their choice. That way, this could still be adapted to KU’s use or  
could be used to feed Sun Identity Manager or Novell Identity Manager  
(where used) from the table, providing good integration with  
commercial IDMS products.

Has anyone else had “bad” performance querying their people branch  
for subjects with particular isMemberOf values. (Or any other indexed  
attribute other than RDN?)

What do people think? And if this sounds good, with or without a  
database table?

-K

PS: For ldappc version 2.0 I propose a more extensive refactoring of  
the code to support multiple plugins to provision things other than  
LDAP. I might actually propose that the name of the product be  
changed to rbacpc (role based access control provisioning connector).  
I have ideas about this, but let's get the work started on ldappc  
1.0.1 first.