Rich Megginson wrote:
Frerk.Meyer@xxxxxxxx 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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
