[Date Prev][Date Next]
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
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.
University Of Athens, Greece.