Frerk.Meyer at Edeka.de wrote: >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' > > Right. But then moving an entry from one group to another becomes problematic. Even if the server supports the modrdn or subtree rename operation, it can be a problem for apps that expect the entry DN not to change. >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 > > Actually, this can be a very expensive operation when you have more than several hundred members of a group. There is no good way in LDAP to efficiently retrieve a large number of values for a single attribute. We need to solve this problem if we want to use standard static group semantics. >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!) > > Is this really the most often used case? Which applications use this case? >Worst for the question: who are the members of a group (if no clever >indexing/caching) > > In FDS with Roles this is a simple search (nsRole=<DN of role definition>) >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 > > > >-- >Fedora-directory-users mailing list >Fedora-directory-users at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050613/1af30392/attachment.bin
