[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on Access Control Model draft - grant/deny evaluation rules
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.