Re: [Fedora-directory-users] Ideas for fds [Auf Viren geprüft]

[Rich Megginson]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20050613/1af30392/attachment.bin>