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

[jclowser at unitedmessaging.com]

Rich Megginson wrote:

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

And applications that depend on a particular tree structure or the 
format of the dn are a nightmare, because if you are trying to integrate 
2 of them in the same directory, they probably won't match up.  I prefer 
to allow entries to be more or less anywhere in the tree (grouping by 
some common criteria like "all users", "all groups", "all resources for 
a customer", etc, and sort them out by objectclass or attribute values - 
i.e. this grouping is appropriate for administering your directory and 
keeping it organized, but is not necessarily a good way to organize 
things for application logic.  Example: if you have an 'engineering' 
group that is defined as all users under ou=engineering,ou=people,o=isp, 
and apps depend on a users position in the tree do access control, 
email, etc to the "engineering" group, that's just bad, because 1) 
people can't be in both the engineering group and marketing group at the 
same time, and 2) moving a user from one "group" to another can be 
really painful (esp if they are part of a lot of static 
groupofuniquename groups, populated in "owner" and "manager" dn based 
attributes, etc throughout the directory).

I've never considered this a "group" per se, but I think I understand 
your point - Sun's messaging server, for example, defines an entry that 
defines an email domain.  All users and mail lists for that domain are 
"grouped" under that domain entry, and the server only honors email 
addresses in that domain if they are under that domain entry, without 
caring _where_ under that domain entry they are.

I think this is a pretty good model, I've just never thought of it as a 
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
>
> 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.

It's definately shown that this does not scale well in all cases, but 
it's the most easy to understand, and is the most "obvious" form of group.

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

I'd say any app that uses groups for authentication, where you have 
different "groups" of users that have different roles - i.e. can I 
access this web page?  Can I use this feature?  What part of the 
directory can I write to?  However a group is defined, a group is often 
used to determine access.  I would have to agree that this is probably 
the most used in my experience as well.  Something like an email list 
will want to read a group and do something all the members, but I'd say 
I more often am asking am I part of group/privilege x?

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

I would agree that this is the more reasonable approach for a lot of 
cases, but I also have to say that the problem lies in apps that exist 
that you have no control over, that know the static group/uniquemember 
method of lookup only.  We can't claim that this is old, obsolete ways 
of doing groups, because there really is no alternative that is 
defined/implemented across all ldap servers and widely accepted like 
groupofuniquenames is.

Unless you are selling an ldap server implementation, people don't tend 
to write LDAP apps to a specific implementation, so 
groupofuniquenames/uniquemember is the most "universal" way to do a 
"group".  (OK, grouping by common values in some attribute is just as 
universal, but I don't think most people formally consider this as a 
"group" so much as a way to do this that doesn't involve groups, if that 
makes sense.  Well, maybe netscape's groulOfURL's _is_ a formal way of 
doing this, but is not widely accepted.)

>> 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.
>
> 4) Simple 'group' attribute

Again, something I never really considered a "group" - at least not from 
an application level perspective, though technically speaking I guess it 
is (kinda like saying all guys named joe make up a group) :).  I would 
say also that nsroles (as well as "memberof") is just a refinement of 
this form of group, in which the attribute can be populated dynamically, 
and/or does reference some other entry someplace.

I've always been kinda leary of this type of group because of the 
challenge of properly securing it.  Consider the following:

1.  I don't want a user to be able to administer their own roles - easy 
enough to restrict if I'm careful setting up my aci's.
2.  I want an admin in engineering to be able to define members of the 
engineering group.  I want an admin in HR to define members of an HR 
group.  Assuming nsRoles, I now have 2 groups that need to edit the same 
attribute, but I won't want engineering to be able to make the user a 
member of the hr group, and vice versa.  This is easy to set up with 
traditional static groups, but gets complicated with nsRoles, and 
doesn't scale well to a large # of groups.
3.  You have to be sure you don't define groups around an attribute that 
the user can edit themselves, unless that is ok for your uses (i.e. for 
mail lists, it might be ok, but for admin groups, it probably is not).

>> 5) Filtered Groups/ Roles
>> Most flexible membership through arbitrary matching criteria through
>> LDAP search string (beware of the performance!)
>
I think this is where this all started, with me asking for a dynamic way 
to populate uniquemember :)

>> 6) Hierarchical groups/roles
>> Groups or Roles which may contain other groups or roles
>>
>> 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.
>
The problem with this is that we don't always get to choose the "best" 
application based on it's ldap integration.  Business decisions are 
based on broader criteria than that :)  So, we get stuck with some of 
these periodically.

To solve this, we need to get wide spread acceptance for a different way 
of doing groups, such that they can be/are implemented in any LDAP 
server (dynamically populating them can be a feature of a particular 
server, but the _definition_ - aka schema - of the list should not be).  
You have to change the mindset on how people define groups in ldap.  
FWIW, nsroles _could_ fit that bill - there is nothing saying we can't 
define and manually populate the attributes to mimic nsroles in any ldap 
server, it's more that vendors haven't written apps to work that way. 

Consider how to implement the following (examples I've used through this 
thread):
1.  Mailing lists.  If the mail server that supports this allows you to 
configure message size limits, header/footers, moderators, etc for each 
group, you can't (and don't want to) store this as attributes in each 
users entry.
2.  VPN Templates - each template defines host access lists, times, etc, 
and a user can be a member of multiple templates to define a merged view 
of their access.

You could populate nsrole with the dn of an entry that is both an nsrole 
and a mail list or vpn template, which contains things like the mail 
list's sizelimits, headers/footers, etc or a vpn templates host list, 
access times, etc.  You could also do this as a separate attribute for 
each app (i.e. memberofLists in the users entry containing the dn or 
email address of the list's they belong to, and memberOfVPNtemplates 
that contains a list of dn's or vpn template id's to let the app find 
the vpn template entries a user is a member of).  You don't want to use 
CoS to put those values in a users entry, because you'd mix and merge 
list or vpn template info inappropriately.

Keep in mind also the amount of work to change something - i.e. what if 
the email address of a group changes, do you want to have to update 100k 
users?

 - Jeff