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

[Frerk.Meyer at Edeka.de]

>>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