Actually there are more kinds of 'groups' in a FDS / Netscape/ Sun LDAP Directory Server than just group entries: 1) Treenodes / Entry DN Every node defines a group of its subnodes and leaves. If a person entries is under some organisation and organisationunit nodes, it is member of the organisations and organisationalunits. Membership can be deduced from the DN of that entry. Search all person in a subtree are the member of that 'group' 2) Classical static groups A group entry has a multivalued attributes with references (DNs) of all members. Best for the question: who are the members of a group Worst for the question: to which groups does an entry belong 3) 'Reverse' or 'forward referencing' groups aka NSroles A person entry has multivalued attribute with references (DNs) to all group (role) entries it is member of. Best for the question: to which groups does an entry belong (the most often used case!) Worst for the question: who are the members of a group (if no clever indexing/caching) 4) Simple 'group' attribute Some simple entry attribute holds the names of all groups/roles an entry is member of. There is no special entry for that group or entry, just membership by name. 'Department' are something similiar is a candidate for this. 5) Filtered Groups/ Roles Most flexible membership through arbitrary matching criteria through LDAP search string (beware of the performance!) 6) Hierarchical groups/roles Groups or Roles which may contain other groups or roles So in this broader sense LDAP-Clients/Applications should get smarter and have should have a more flexible configuration, or they should use adapters which abstract the whole LDAP-Server like in Security-Reams of Java Application Servers where the source for authorization and authentication can be exchanged with a database or property file. Fropm my experience the Apache Jakarta Tomcat 5.5.7 supports NSRoles in its JNDIRealm out of the box even without mentioning it. It combines the membership in LDAP Groups AND LDAP Roles to provide an application with the sum as Java/Application roles. I implemented my own custom Realm according to the JAAS standard and therefore I'm able even to interpret filtered and hierarchical groups/roles and hide them from the application. It is possible to use the declarative Access Control Instructions in a java application, which is not possible with standard realms. But as long as someone has to support some closed source, braindead, legacy code with an over-simplified LDAP connection I would be against curring that disease on the server-side, perpetuing the problem into the future and encouraging those implementations even in future developments. Instead some kind of LDAP-Proxy-Super-Adapter comes to my mind: it would use and understand all those variations of groups and present them to an application as being a classical static group. It would be very configurable in every aspect. Otherwise I'm afraid to much of application logic moves into the directory server like PL/SQL only for LDAP. Frerk Meyer EDEKA Aktiengesellschaft GB Datenverarbeitung Frerk Meyer CC Web Technologien New-York-Ring 6 22297 Hamburg Tel: 040/6377 - 3272 Fax: 040/6377 - 41268 mailto:frerk.meyer at edeka.de
