Re: [ldapext] LDAP Groups topic split-out

[Simo Sorce <[e-mail]>]

On Thu, 2015-12-03 at 16:33 -0800, Jordan Brown wrote:
> On 12/3/2015 3:12 PM, Charlie wrote:
> > 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
> 
> 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.)

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.

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

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.

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

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

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

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

> D.5
> 
> posixGroup has memberUid as a MAY attribute and so *can* represent empty sets.
> 
> 
> > 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.
> >
> 
> 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.

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