[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "Roles" in OpenLDAP?


Dynamic groups are always supported for ACLs in OpenLDAP 2.2. The only thing
the dynamic group overlay (--with-dyngroup option) does is allow using
LDAPCompare to test the membership of a dynamic group. If all you need is ACL
support you don't need this option.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


Motivated by your answer about Dynamic Groups, Roles or whatever, I would like to ask something that might end a slight misunderstanding about the usage of dynamic groups and the provided functionality. A lot of people think that may take advantage of OpenLdap dynamic groups and use them through various services in order to provide the dynamic groups functionality inside those services. (e.g. in radius server: users that belongs to the undergraduate dynamic group, to postgraduate dynamic group or faculty dynamic groups etc etc). In my opinion this is only possible if you include, the service or a class of service, inside the dynamic group definition (eg inside the dynamic group filter) in order to distinguish the groups that refers to one or other service*. If I am not the one who misunderstand the current dynamic group implementation, the previous solution will lead to noticeably, ldap server, performance degradation, since ldap server should examine the membership of all defined dynamic groups no matter which service is asking for. In a fictional scenario where all internet services store users profiles in a directory server the number of dynamic groups will grow to levels that never designed for.
So as long as there is no way to relate a group of dynamic groups with a specific attribute (e.g. radius dyn.group1, radius dyn.group2,.... with the attribute radius-role), (or there is ? **) there is no way to provide an early stage selection of the groups that should be tested, and it isn't advisable to build a service that directly uses openldap dynamic groups. Instead service specific dynamic groups resolution/membership should be a client task, otherwise we end up with a stumped ldap server. Wrong or right?
I have to admit that no matter what the conclusion will be, I will be glad, since I could, eventually, drop all those lines of code I wrote inside various services, during the days of openldap 2.0 & 2.1, in order to implement for our university the concept of dynamic groups.


*All previous are applied in a case where we all agree that groups definitions, are service specific, and it is rather rare to have usable common representations/definitions for different services.
** If it is true that there is no way to define groups of dynamic-groups that may be selected by using deferent attribute, then you may take this as a humble feature request.

Nikos Voutsinas
University Of Athens, Greece.