Subject: [ldapext] LDAP Groups topic split-out

From: Charlie <[email-masked]>
Date: Thu, 3 Dec 2015 18:12:54 -0500

After reading David Foster Wallace on set theory, I wrote an RFC a
couple years back to address the lack of a generic or globally useful
grouping mechanism in LDAP-accessible directories.  Comments are
welcomed.

http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt

If you're not up for a long-read, I would recommend just reading
"Appendix D:  Other Efforts and their Shortcomings" which explains all
the attempts to date and how they've failed to gain traction.

Projects continue to try to solve their individual problems instead of
working towards a truly generic grouping mechanism that will suit all
needs, so nothing's progressing.  Simo mentioned this in the context
of FreeIPA, for example - they broke their implementation of RFC2307
and moved on, rather than helping Andrew Findlay create a standard
that supported empty groups.  It seems like each of us is focused on
our own potato patch.

--Charlie

---

From: Jordan Brown <[email-masked]>
Date: Thu, 3 Dec 2015 16:33:38 -0800

> http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt

3.1.

Properly, Boy Scout and Scout are capitalized.

In the general case, I'd say that it's equally correct to say that the list of 
Scouts is an attribute of the troop and to say that membership in the troop is an 
attribute of the particular Scout. It's an N:M relationship; it can be approached 
from either direction.

(I had not realized until I got to the discussion in D.2 that a mailing list was 
best served by member-of attributes.  One would think that it would be best served 
by a member-list attribute, but you're absolutely correct that using a member-of 
attribute reduces the number of queries in the common case.)

For an indexed database, it's probably OK to represent the relationship in either 
direction.  For a database that understands the relationship, the relationship 
might be visible on both sides and the connection automatically maintained.

For simpler databases, indeed maintaining "member-of" is probably better, both 
because it's convenient for the common queries and because it's probably a smaller 
list than the "members" list.

(But note:  it's not at all obvious which variation is better from an access 
control standpoint.  Is it more likely that you will want to hide the membership 
of group X, or the list of groups that user Y is a member of?  Presumably if you 
want to do either, then you need to ensure that that membership linkage, however 
it is presented in the directory, is subject to access control restrictions.)

3.4.

Empty sets are also useful in trivial cases, e.g. when creating a set and before 
populating, and as a possible intermediate state while adding and removing members.

3.5

I'm not convinced that "proxy" objects (which you call "dummy" objects) aren't the 
right answer.  Directly referring to external objects assumes that there's no need 
for auxiliary data about those objects.

(Hmm.  Is there a need to describe auxiliary information about a particular 
membership relationship?  For instance, for a mailing list, might one want to 
maintain a count of messages from a particular list to a particular user that have 
bounced?)

4.4

I'm not convinced that an undefined "scope" attribute is helpful.

4.5

psetMembership seems like overkill, though its ability to represent dynamic sets 
is interesting.

5.3

If recursion is always expanded by the client, there's no need for timeouts on 
queries to prevent DoS.  The clients can decide on their own when to stop recursing.

C.1, C.2

I thought that memberOfPset contained DNs.

D.5

posixGroup has memberUid as a MAY attribute and so *can* represent empty sets.

> that supported empty groups.  It seems like each of us is focused on

Actually, here in the Solaris Naming organization, mostly our assumption is that 
we have to live with whatever the directory gives us, that the directory was 
established by the enterprise before we arrived on the scene and so our ability to 
influence it is minimal. We might participate in an effort such as this one to try 
to nudge the future in a desirable direction, but the assumption is that no one 
scheme will ever achieve such dominance that we can ignore the others.  Of course 
I would be happy to be proven wrong so that we could remove a bunch of flexibility 
that's associated with the need to interoperate with such a variety of schemata.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 11:02:30 +0100

> http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt

Although you will likely claim that your I-D also describes the problem in
general you're already endorsing a particular solution. :-/

I suspect that your mixed use of values in attribute 'psetMembership' will
rather contribute to the "hodgepodge of LDAP schema" you criticize than solving
problems.

Personally I don't see a strong need for generic "ur-objects" because one can
easily define such a schema for a particular deployment with custom schema with
particular semantics.

> the attempts to date and how they've failed to gain traction.

I agree with some of your points therein. But you have a wild mix of true issues
on one side and bad common practice with dummy objects on the other hand.

I'd say we should:
1. fix true issues (e.g. empty-group-problem) with a new I-D.
2. Add text (implementation notes, security considerations etc.) to prevent bad
practice.

For 2. you will never find text which prevents all people to shoot themselves in
the foot.

Ciao, Michael.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 10:23:39 -0500

> it is presented in the directory, is subject to access control restrictions.)

Your points are correct, in fact in our project we do populate memberof
automatically based on the member attribute (including unrolling nested
relationship for the pain of those that loves non-unrolled memebrofs in
AD) but we also prevent access to the memberof attribute to some classes
(like unauthenticated guest sessions, etc..).

The main issue with dealing with memberof is access control around the
"add" operation. ManagerX for GroupX should be able to add any user to
its group but shouldn't be able to add users to other groups or random
objects. So a naive ACL that allows ManagerX to add memberof attributes
to any user won't work. You need an ACL to express the concept that
ManagerX can add only memberof attribute where the value is a group on
which he is directly (or indirectly via group membership in a manager
group) a "manager". (I am looking at 5.5 here now I realized and do not
agree with it's optimism :-)

Some ACL systems allow this, some do not, I believe a standardized base
ACL system (possibly extensible with additional custom allow rules) that
is reasonably complete and featured and also *fast* becomes a necessity.

3.3. This is basically hinting at the need to use Role Based Access
Control, this is something many systems implement by using a group to
represent a Role, and then performing access control and associating
permissions to that group.

> maintain a count of messages from a particular list to a particular user that have 

We introduced external members in our schema because we needed to
represent members of a foreign realm (which we trust) without being able
to replicate information (one way trust incoming only). The only
information being IDs transmitted at authentication time.
We do not use dummy objects, but we created a proper mechanism to
resolve and store these IDs.

4.1 pragmaticSet has a MUST on description, as much as I understand the
intent I think it is a mistake, as it will force admins to put trash in
there when they do no want to put anything. I think it is better to
allow nothing than to pollute the field with trash.

As for the pSet being auxiliary, that may be a good idea, but I would
also provide an structural class for instances where a pre-existing
object is not available, it doesn't have to be a new one, just a
recommended to use one.

4.2 the MUST on memberOfPset will make things very hard. This is
conceptually the same as forcing a member in groupOfNames.
As it forces the removal of the objectclass and all attributes to remove
the last memberOfPset, this is really bad.

> psetMembership seems like overkill, though its ability to represent dynamic sets 

I am no sure caseExactMatch etc are a good match for this object though
as attribute names are case insensitive.

> I thought that memberOfPset contained DNs.

It is defined with DN sytnax, so the value "drools" also surprised me.

> that's associated with the need to interoperate with such a variety of schemata.

Same here, most of our choices in FreeIPA did not come out of a
willingness to resolve our own problem only, but due to a number of
constrains based on what clients can do today.

The ability of pset to dynamically generate atttributes to accomodate
legacy service is great but the cost of doing it at query time will
simply be impossible to sustain in any moderately sized environment.

That is why in FreeIPA we generate atrtributes at add time (we generate
both the memberof and the memberUid attributes, plus we have a full
"compatibility" tree that re-represents all users with rfc2307 semantics
(we primarily user rfc2307bis-like in the main tree.
This is done so that these objects are computed once, as LDAP is
generally write-seldom, read-often.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 16:36:26 +0100

Simo Sorce wrote:
> in fact in our project we do populate memberof

But it was a fault to take the very same OID and NAME for that attribute like
'memberOf' in MS AD because the semantics are different there (no nested groups
referenced).

> "add" operation.

Yupp. Needs value-based access control. Does 389-DS provide ACIs like this?

Ciao, Michael.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 11:04:52 -0500

> 'memberOf' in MS AD because the semantics are different there (no nested groups

I think fault or not is a matter of perspective, we do use this
attribute for members of a group, as the description says.
But yeah it behaves in a slightly different way than AD does and in
retrospect we may have used 2 separate attributes.

> Yupp. Needs value-based access control. Does 389-DS provide ACIs like this?

Yes, it actually does, but we do not allow to modify the memberof
attributes directly, we consider it an operational attribute (although
not marked as operational :-) which is always set through an operation
on the member attribute of the target group.

Simo.

---

From: Charlie <[email-masked]>
Date: Fri, 4 Dec 2015 12:30:22 -0500

> general you're already endorsing a particular solution. :-/

I have indeed endorsed a particular solution, but I support any effort
that will address any of the structural problems exposed by real-life
daily directory administration.

In section 3 of my I-D I enumerated the requirements for a generalized
solution to all grouping problems in real-world directories.  Any
solution that satisfies those requirements will make the world a
better place.  It doesn't have to be MY solution.

But pragmatically, everyone is going to end up using memberOf
attributes eventually.   This should be clear by now; it's certainly
clear to our friends in Redmond and Raleigh.  We can fight this and
make it painful for everyone involved - or we can accept it as
architecturally correct, and create useful LDAP standards for
programmers working towards system interoperability.

--Charlie