Comments on Access Control Model draft - grant/deny evaluation rules

[rvh@qsun.mt.att.com (Richard V Huber)]

I'm afraid this one is a bit long, but at least it's the last of my
comments on the access control model draft.

While the current draft has improvements over earlier ones, I think
there are still some ambiguities in the grant/deny evaluation rules
(Section 4.3).

I agree that "more specific policies MUST override less specific ones",
but there are some places where it is not clear which policy is more
specific.  There are also some missing elements in the precedence
lists, and there are some interactions among different precedences that
need to be clarified.

Some of the things that I don't think are clear in the current draft:

 - Groups and roles may contain other groups and roles.  Subtrees may
   contain groups and roles.  Since groups, roles, and subtrees are of
   different precedence, the interactions need to be spelled out.

 - Subtrees contain subtrees.  I assume that subtreeACI for a contained
   subtree has precedence over subtreeACI for the containing subtree,
   but that doesn't seem to be explicitly stated.

 - There are some things missing from the precedence lists (e.g.
   "authzID-dn:" vs. "authzID-u:", precedence of attribute
   specifications).

 - There are some interactions between precedence lists that are not
   well defined.

 - authnLevel checking is not well integrated with the rest of the
   evaluation rules.

 - The term "more specific" is useful in guidelines, but it should not
   be used in actual requirements since it is not well defined.

I've attached a revised version of the precedence lists and the access
decision algorithm below.  It attempts to resolve the issues above.

Rick Huber

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Precedence of Scope Types:

  1. Entry

  2. Subtree
     For a given subject DN (including authentication level) and target
     DN, subtreeACI lower in the tree take precedence over those higher
     in the tree.

Precedence of Subjects within a Scope:

  1. ipAddress

  2. Wildcarded DNS name
     If multiple wildcarded DNS names are applicable, they are of equal
     precedence.

  3. authzID distinguished name ("authzID-dn:")

  4. authzID userid ("authzID-u:")

  5. this

  6. role
     If the DN of a role or a group appears in a role (e.g. appears as
     a value of roleOccupant in an organizationalRole), it is
     recursively expanded.  For determination of precedence, the
     resulting expanded collection of names is considered to have come
     from a role regardless of the original source.

  7. group
     If the DN of a role or a group appears in a group, it is
     recursively expanded.  For determination of precedence, the
     resulting expanded collection of names is considered to have come
     from a group regardless of the original source.

  8. subtree
     Subtrees may contain groups and/or roles.  They should be
     recursively expanded.  For determination of precedence, members of
     groups or occupants of roles that apply because (after recursive
     expansion) the group or role is contained in a subtree are
     considered to have come from the subtree regardless of the
     original source.

  9. public

Precedence of Attribute Specifications

  1. Access controls for a list of specific attributes (regardless of
     the number of attributes on the list) are all of equal
     precedence.

  2. Access controls specifying "[all]" attributes are of lower
     precedence than specific lists.

Precedence of grant/deny:

  Deny takes precedence over grant

Precedence of Authentication Levels

  1. ACI that specifies a specific authentication level applies only if
     the subject has authenticated at the specified level.  It takes
     precedence over ACI that specifies the same subject with "authn"
     or "unauthn" authentication level or with no authentication level
     specified.

  2. ACI that specifies "authn" or "unauthn" has lower precedence.

  3. If the authentication level is omitted, it is treated as though
     "authn" had been specified.

Default

  Deny is the default when there is no access control information or
  when evaluation of the access control information yields no result
  that allows the requester access.

Access Decision Algorithm

  1. Determine all the entryACI and subtreeACI values which could apply
     to the target DN which is being accessed.  This is the DN of the
     entry which is being queried in a search, modified, deleted, etc.
     Precedence of values from different ACIs are handled according to
     the "Precedence of Scope Types" above.

  2. Determine which of the collected ACI values (determined in step 1)
     apply to the bound DN.  Process one Subject Type at a time in
     order of precedence from the "Precedence of Subjects within a
     Scope"  Within each Subject Type, apply the the precedence rules
     for Authentication Level from "Precedence of Authentication
     Levels".  If at least one ACI value exists for a Subject Type when
     all ACI values for that Subject Type have been processed, proceed
     to Step 3 without processing any additional Subject Types.  If no
     ACI values remain after processing all Subject Types, access is
     denied.

  3. Evaluate the remaining ACI values and determine a grant/deny
     decision.  For permissions that apply to attributes rather than
     entries, if conflicting ACI values exist for one attribute, apply
     the "Precedence of Attribute Specifications".

  4. If conflicting values still exist, deny takes precedence over
     grant.

  5. If more than one ACI value remains, union semantics apply.

  6. If there is no grant for one or more of the permissions required
     for the operation in question, access is denied.