[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Model draft - grant/deny evaluation rules
Kurt's comments on my comments are preceeded by colons. My replies are
on the lines that do not have colons.
Rick Huber
: >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.
If groups and roles are not recursively evaluated, I think that the
principle of least surprise will be violated - it won't work the way
people expect it to. If a group DN appears as a member of another
group, I believe the expected behavior is that the members of the
"inner" group get the access granted to the "outer" group. How do we
get this behavior if groups/roles are not recursively evaluated? As
for subtrees, are you saying that a group or role should not get the
access that is granted to a subtree containing the group?
: > - 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.
I wrote my comments to reflect my preference, but I could live with
Kurt's version. The important thing is to explicitly state how it
should work to avoid implementaion inconsistencies down the road.
: > - 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.
OK. how about "... applicable ACI values from subtreeACI lower in the
tree take precedence over those higher in the tree."
: >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.
Bob Blakley sent some mail about this explaining the precedence. This
isn't a subject type I would really want to use, but if you DO want to
use IP address to determine access controls, I agree with Bob that it
needs to have high precedence.
: > 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.
:
But then we have to define a well-ordering of authentication levels,
and I believe that is a rathole. And the rathole reopens every time
someone comes out with a new SASL mechanism.
: > 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.