[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Model draft - grant/deny evaluation rules
At 11:14 AM 4/3/01 -0400, Richard V Huber wrote:
>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.
I would recommend that subtrees, groups and roles not be
recursively evaluated.
> - There are some things missing from the precedence lists (e.g.
> "authzID-dn:" vs. "authzID-u:", precedence of attribute
> specifications).
I believe they should have the same precedence as they are
equally specific.
> - The term "more specific" is useful in guidelines, but it should not
> be used in actual requirements since it is not well defined.
I concur.
>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.
lower and applicable / higher and applicable.
>Precedence of Subjects within a Scope:
>
> 1. ipAddress
I don't understand why ipAddress is viewed as being more
specific than an authzID.
> 2. Wildcarded DNS name
> If multiple wildcarded DNS names are applicable, they are of equal
> precedence.
I don't understand why ipAddress is viewed as being more
specific than an authzID.
> 3. authzID distinguished name ("authzID-dn:")
>
> 4. authzID userid ("authzID-u:")
All forms of authzID should have equal precedence.
> 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.
I note:
X.501(93) 16.4.2.3 AuthenticationLevel
AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem.
> 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.