>>1) Treenodes / Entry DN >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. Most applications first search the DN of a person by its uid (or email adress or cn) so the DN may vary. Second I currently use the hierarchical approach because NSroles are inherited along the tree. So if the user help desk creates a user in the right tree leave, they automatically get the roles inherited they need for our applications. No manual administration of static groups needed. I wouldn't even need NSroles, if all node names would be translated to Java/Applications-Roles in the Java-World. It would be really great if a moved person would belong to the same groups and roles afterwards. Today I correct it manually and have to write a tool that does it automatically. >>3) 'Reverse' or 'forward referencing' groups aka NSroles >>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? Every Java Application I know of. For a use rto login there is always this sequence: - anonymous bind to search the users DN from uid - try to bind with DN and password - if success get all group memberships of this user: o search all group entries where the DN is member o read attribute NSRoles o return the sum of both as java/application-roles Tomcat returns the LDAP group membership as their 'cn' and the NSroles membership with their 'dn'. Only my LoginRealm is able to return both by their 'cn'. Another wish: rename nodes which have leaves. 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
