Subject: [ldapext] Additional constraints for attribute values in subschema

From: Michael Ströder <[email-masked]>
Date: Wed, 23 Apr 2008 16:37:25 +0200

HI!

I'd like to discuss the idea of defining and publishing additional 
constraints on attribute values in the subschema subentry in a 
standardized way so that schema-aware clients can obey these constraints 
guiding the user and servers can enforce these constraints when entries 
are added or modified.

Please let me know what you think about explanations below.

Ciao, Michael.

----------------------------------------------------------------------

Sometimes it's not sufficient to simply specify an existing LDAP syntax
or SINGLE-VALUE flag for an attribute type to express more specific 
constraints on attribute values.

Such constraints are considered most times to be part of a local 
directory profile defined by the DSA administrator, but it is not 
limited to this purpose. Schema designers MAY also define additional 
constraints in published standards. Also servers MAY enforce constraints 
not specified like explained herein (e.g. a unique value constraint).

There are several possible approaches for this:

1. Extend attributeTypes in subschema subentry with additional 
parameters. This would require to change standard schema definitions for 
locally profiling a directory which is widely considered bad practice. 
Also compability to older implementations is a risk.

2. Proprietary server-configuration like already implemented in server 
products. The caveat is that an interactive schema-aware client cannot 
retrieve this constraint information in a standardized way. So guiding 
the user to do the right thing is not possible.

3. A subentry specification for a part of the DIT. Unfortunately this 
mechanism is AFAIK not widely supported in current server 
implementations and needs more work.

4. My proposal is to add a new attribute 'attributeConstraints' to the 
subschema subentry which associates additional constraints with a 
certain attribute type by OID crossref similar like DIT content rules do 
for structural object classes.

Possible constraints:

REGEX
Regular expression defining a valid syntax of attribute values

VALUES
Explicit set of possible attribute values. (The constraint itself could 
also be achieved by REGEX but it enables the client to provide a typical 
select list at the user interface.)

LDAPURI
LDAP URL specifying a set of possible attribute values as LDAP search 
results. If attrs is not specified the DNs of the found entries are the 
set of possible values.

OPTIONS
Set of possible tagging attribute options or option tag/range prefixes.

MAXNUMBER
max. count of multi-valued attribute values

MAXBYTELEN
maximum numbers of bytes

MAXCHARLEN
maximum lenght of a character-based string (depending on syntax)

Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not 
combinations of these parameters.

Examples (lines partially wrapped in this message):

For constraining attribute type 'o' to a set of 'o' attribute
values of already existing company entries. (This might cause problems 
if only one subschema subentry is present for the whole DIT.)

attributeConstraints ( 2.5.4.10
   LDAPURI 
ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?(objectClass=organization)
)

For attribute type 'manager' be chosen from DNs of existing entries:

attributeConstraints ( 0.9.2342.19200300.100.1.10
   LDAPURI 
ldap://dir.example.com/dc=example,dc=com??sub?(&(objectClass=inetOrgPerson)(title=Manager))
)

For attribute type 'jpegPhoto' of restricted size and to a single value 
(overrides multi-valued default):

attributeConstraints ( 0.9.2342.19200300.100.1.60
   MAXNUMBER 1
   MAXBYTELEN 4000
)

Restricting a (proprietary) attribute 'gender' to values specified in 
ISO standard 5801:

attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7
   VALUES ( '0' $ '1' $ '2' $ '9' )
)

_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 24 Apr 2008 15:29:26 -0700

> guiding the user and servers can enforce these constraints when  

Constraints upon the LDAP string encodings of values or constraints  
upon abstract values.

For the latter, I would think a mechanism to specify an ASN.1  
constraint upon the value would work reasonable well.  (Of course,  
implementation ease would depend on how ASN.1 aware your code is  
already.)

For the former, well, given multiple possible encodings per value, I  
don't think it will work well.  For instance, regex'ing works best  
only when the DSA has a canonical string representation of the value.

-- Kurt

> ldap://dir.example.com/dc=example,dc=com??sub? 
> (&(objectClass=inetOrgPerson)(title=Manager))
> )
>

---

From: Steven Legg <[email-masked]>
Date: Mon, 28 Apr 2008 17:22:47 +1000

Hi Michael,

> Please let me know what you think about explanations below.

Another problem is that the underlying ASN.1 type for attributeTypes,
i.e., AttributeTypeDescription, is controlled by the X.500 working group.
If the LDAP-specific encoding is extended but the X.500 definition isn't,
then there is no way to transport the additional parameters in the X.500
protocols (unless they can be expressed as an ASN.1 constraint).

> for structural object classes.

Approach 4 is the way I would tackle it.

> Regular expression defining a valid syntax of attribute values

Kurt has already made the point the REGEX works better at the level
of ASN.1 abstract values (as opposed to the particular encoding of
the value), and it so happens that ASN.1 has a PATTERN constraint
for applying a regular expression to a character string. It can also
apply constraints to specific components of complex syntaxes, which
would make it easier to target the right part of a structured value.

A limited subset of ASN.1 constraint notation would be sufficient
to cover the REGEX, VALUES and MAXCHARLEN cases, and would provide
an obvious upgrade path for the future.

> max. count of multi-valued attribute values

The size of a value transferred in protocol depends of the encoding rules
used and even on options used within a set of rules. An LDAP-specific
encoding of a value will usually be a different length to its BER encoding
or GSER encoding. A specification would have to be very clear about how
the length is calculated. Perhaps it's not worth the trouble.

> combinations of these parameters.

It don't see any great problem in allowing parameters to at least be combined
by union. A set of values is a union after all.

> ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?(objectClass=organization)

I'd much rather see the LDAP-specific encoding of any new LDAP syntax defined
to be the GSER encoding with respect to a specified ASN.1 type. It's easier to
support for those of us with GSER decoders, and makes no real difference to
those who hand craft their parsers. I imagine the GSER encoding of an
attributeConstraints value would look something like this:

     { type o, ldapURI "ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?
     (objectClass=organization)" }

Regards,
Steven