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

[Frerk.Meyer at Edeka.de]

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