Re: [ldapext] A twisted extensible match proposal

[Steven Legg <steven.legg@eb2bcom.com>]

Jim,

Jim Sermersheim wrote:
> We're thinking of proposing an extensible match to solve a particular
> problem, but this matching rule sort of pushes the normal use of the
> MatchingRuleAssertion.matchValue field.
>
> Here's an abstract representation of the requirement:
> Say I have a blacklist in the form of a DN-syntax attribute (the member
> attribute is a good example)
> I want to search for all people with blue eyes, but I want to exclude
> all people in my blacklist. So I want an extensible match where the
> 'type' names the attribute which holds my blacklist and the 'matchValue'
> contains the name of the object holding my blacklist. The matchValue is
> the part that is twisted * it's not really the assertion value, the
> assertion value is really the name of the object being tested. So if my
> blacklist is held in an attribute called 'exclusions' on an entry named
> cn=acquaintances, this would be the string filter:
>
> (&(eyeColor=blue)(!(exclusions:1.2.666:=cn=acquaintances)))
>
> So two questions:
>1 ) Does this push the semantics of the MatchingRuleAssertion.matchValue
> too far?

It pushes too far the semantics of MatchingRuleAssertion rather than
matchValue. Filter items are evaluated against nominated attributes
in a candidate entry, but the entries you expect to be returned typically
won't have an exclusions attribute, and even if they did the attribute would
be ignored.

>2 ) Is there a more obvious way to solve this problem?

There is a neater way. I'll let you decide whether it's obvious.

What you want to know about a candidate entry is whether its DN
is a member of a set of DNs that is the result of evaluating a
subexpression. The recently discussed entryDN operational attribute
gives us a way to nominate an entry's DN for testing. The "member of"
aspect can be indicated by the matching rule, leaving the assertion
value to specify the subexpression.

For your purposes, the set of DNs is specified by a base entry and
an attribute type with DN syntax. This is a sufficient definition
for the assertion syntax:

Subset ::= SEQUENCE {
    baseObject  [0] DistinguishedName,
    type        [1] AttributeType
}


So now, I would express your query like so:

    (&(eyeColor=blue)(!(entryDN:1.2.666:=
        { baseObject "cn=acquaintances", type exclusions })))

The assertion syntax is GSER encoded. Appropriate names for 1.2.666
would be "memberOf" or "withinSubset".

Dereferencing of DNs within queries is something that keeps coming up
and Subset could be extended to deal with other requirements.
In the more general case it would be useful to be able to specify
a collection of entries from which to extract DN syntax attribute
values, instead of just one entry. The obvious form for that is a
search filter, with scope and derefAliases for completeness.

The DNs we might want to extract could also be in a component of the
nominated attribute values, so we can add an optional ComponentReference.

The more general Subset looks like this:

Subset ::= SEQUENCE {
    baseObject    [0] DistinguishedName,
    scope         [1] ENUMERATED {
                      baseObject    (0),
                      singleLevel   (1),
                      wholeSubtree  (2) } DEFAULT baseObject,
    derefAliases  [2] ENUMERATED {
                      neverDerefAliases    (0),
                      derefInSearching     (1),
                      derefFindingBaseObj  (2),
                      derefAlways          (3) } DEFAULT DerefFindingBaseObj,
    filter        [3] Filter OPTIONAL,
    type          [4] AttributeType,
    component     [5] CHOICE {
                      reference  [0] ComponentReference
                      -- [1] reserved for an alternative offered by XED --
                  } OPTIONAL
}

There's no technical reason why MatchingRuleAssertion.type and Subset.type
have to refer to attributes with DN syntax. It is only necessary for
them to refer to attributes with the same syntax (e.g. both Integer),
with equality determined with respect to the equality matching rule of
MatchingRuleAssertion.type .

Regards,
Steven


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext