RE: creatorsName/modifiersName referential integrity

[Howard Chu <hyc@highlandsun.com>]

> As many have mentioned, this is a problem not just with
> creatorsName and modifiersName, but with any attribute of syntax
> DN (members of a group) or any attribute which contains a field
> of type DN (Access Control Items, ACIs [ACIs as an attribute are
> not defined, and in fact are implementation specific]).
>
> I think referential integrity definitely affects
> interoperability--especially when access control is considered.
> Let me give an example.
>
> Step 1.  User John Smith, "cn=jsmith, ou=abc, o=def, c=us" is a
> vice president and consequently is a member of several groups
> that give him the right to see financial reports, etc.
> ("cn=jsmith, ..." is in the member attribute of the groups and
> the groups are named in various ACIs).  He is also given explicit
> rights in the tree ("cn=jsmith, ..." is named in various ACIs).
>
> Step 2.  John Smith leaves o=def to pursue whatever.  His object
> is deleted.
>
> Step 3.  Jack Smith is hired as a mail room clerk.  He is created
> as object "cn=jsmith, ou=abc, o=def, c=us" (the same DN).
>
> Case 1: no referential integrity.  DN Attributes are left
> dangling (pointing to non-existent objects).  This case makes
> assumptions about how the DN is stored.
>
> Because the names in the groups and ACIs for John Smith were left
> dangling, and Jack Smith now has what used to be John Smiths DN,
> it appears to the system that Jack Smith is a member of the
> groups and is listed explicitly in ACIs.  Thus a mail room clerk
> has access to confidential financial documents and can manipulate
> the tree.
>
> Case 2: referential integrity.  DN attributes pointing to
> non-existent objects are removed by the implementation.
> Attributes with DN fields that point to non-existent attributes
> are removed by the implementation.
>
> Thus the implementation deletes all references to "cn=jsmith,
> ..." when his object is deleted.
>
> Now when Jack Smith is added using the same DN there is no
> confusion of access control.
>
> My Conclusions:
>
> By not specifying what standard actions should be taken,
> interoperability has definitely been impaired.  Thus this needs
> to be discussed and standard actions should be included in
> updates to RFC 2252.
>
> Thoughts?

Referential integrity is easy enough to handle within the bounds of a single
DSA, but it becomes much more interesting in the context of multiple DSAs
with cross-realm references. This is one of the things that the DCE guys got
right, and the X.500 guys in general have already made a lot of progress on.

There is another solution to your example that doesn't require referential
integrity - use UUIDs. The current NameAndOptionalUID attribute has proper
semantics to prevent any confusion due to deletions and recreations as in
your
scenario. It's not sufficient to solve problems due to renamed entries
though.
(Rather, the definition of the UniqueMemberMatch rule is not good enough.)
To be truly useful this should have been "UIDAndOptionalName" - that would
allow you to locate renamed entries where the UID matches but the DN
doesn't,
and then you could fix the DNs.
  -- Howard Chu, hyc@symas.com
  Chief Architect, Symas Corp.