Add support for Controls

[vanrein]

LillyDAP does not support LDAP Controls yet, it just passes them verbatim. The use is simply a matter of iteration, and perhaps the standardised OIDs could be collected in a perfect hash function.

Functionality that would be useful however, is filtering. One should not pass influential instructions, such as the Proxied Authorization Control without spending attention to it. In general, a filtering function on LDAP Controls would be prudent. Whether an LDAP Control is critical might play a role in doing so.

In addition, one will want to check the presence of a given LDAP Control, and potentially its parsed value and maybe even whether it is critical.

Finally, one will want to send, or attach, an LDAP Control or list of LDAP Controls. Doing this would ideally involve construction from a Quick DER class.

[vanrein]

Perhaps a nice construct would be to use commands for every integer-numbered OID:

• default handling for the given OID [with overridden value]
• require presence [and value]
• forbid presence [when it has value]
• drop when present [if it has value]
• add when not present, with given value
• pass through when present [with given value]
• replace when present, with given value

In addition, a callback might be made when a value is present. So, the interesting information would map a control identifier to

• command code (default initialiser 0 implies the default action, possibly overriding the [value])
• value, optional for some command codes as shown by [extra spec] above
• callback function that returns dynamic command code and [value]

All this could be combined into a union, much like the operations registry, which has a variant that lists comands by numbers, and another by name. This registry could be placed in the LillyStructural component, but it may also be operation-specific, and then added to the opregistry? Various places hardly cost space/time, but might support many constructs in applications! Internally, it would be possible to simply call a new API function lillyctl_filter() -- which would explicitly perform these actions on a dercursor listing the Controls.

[vanrein]

How to generate all this?

We might use gperf once more, and map OID values to table entries. The table entries might specify, using the index derived by gperf:

• oid in the LDAPOID form
• criticality indicates desired critical flag values, or a wildcard value
• opcodes for which the control is appropriate
• command to apply by default
• value to use for the control when not overridden
• packer for the data structure

Note that the packer also implies that we might need supporting packer and/or unpacker structures. In fact we should reason what sort of values we want to use —be it dercursor[] or DER blob— in the various places. It may be prudent to unpack into an array the size of the gperf index size, with pointers to unpacked extensions. In this case, an annotation in the filters may be prudent.

Having this table does not mean we have the .by_name structural description yet. We should generate it afterwards, based on the gperf output function. Note that other functions, such as those made by cmph, are not deterministic and may incorporate changes after a literal rebuild. This means that variations in header/library builds would invalidate the .by_name setup for the gperf generated tables.

An alternative might be to have another indexing mechanism, and only use gperf to generate an index into that system. That would be very much simpler. It is aligns with the usualy approach of specifying array members to gperf. On grounds of the stability of the .by_name mechanism, this is the path we ought to take.

[vanrein]

Commands may be generalised in a number of behaviour aspects:

• input may be required, forbidden, or optional
• invalue may be any, matching, or mismatching
• ifaction may add, remove, replace or pass
• elseaction may add, remove, replace or pass

In terms of these, the commands specified above can be written as:

• default is a special case (but might get its own values above)
• require has input=required, invalue=any|matching, ifaction=pass, elseaction=pass
• forbid has input=forbidden, invalue=any|matching, ifaction=pass, elseaction=pass
• drop has input=required|optional, invalue=any|matching, ifaction=remove, elseaction=
• add has input=forbidden|optional, invalue=any|matching, ifaction=add|replace, elseaction=
• pass has input=optional, invalue=any, ifaction=pass, elseaction=pass
• replace has input=optional, invalue=any, ifaction=replace, elseaction=replace