[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: X.500 vs. LDAP ACL MODEL PROPOSAL comparison
Date forwarded: Mon, 15 Jun 1998 21:20:36 -0700 (PDT)
From: Bob Blakley <blakley@us.ibm.com>
Bob,
A good analysis of X.500 ACLs, I have a few comments/corrections to make
David
>
> TYPES OF ACLS
>
> X.500: 3 types
>
> Prescriptive ACI
>
> Held in subentry
> Protects user attributes of an arbitrary
> subset of entries in a subtree of
> the entry in which policy is defined,
> NOT including root entry of the subtree.
This may not be correct. There was much discussion about this (i.e. whether
the root is in the subtree specification or not) when the 93 standard was
finalised. I am not sure that the final decision was consisently recorded. You
can certainly find clauses in X.501 to support that the root can be in the
subtree e.g.clause 11.3.3 Base.
> Applicability to a particular entry is
> checked via pattern match of
> defining subentry rule vs.
> subtree entry attributes
>
> Entry ACI
>
> Held in entry or subentry
> Protects entry's user and/or system attributes.
> Also (if in entry) can protect self
> (this usage is strongly discouraged
> by X.500 documentation)
> Not applicable to entries except that in which
> defined
>
> Subentry ACI
>
> Held in entry
Only held in administrative points, not in any arbitrary entry.
> Protects entry's subentries
> Not applicable to entries except that in which
> defined
No, not applicable to entries. Fullstop.
>
> LDAP ACL MODEL DRAFT: 1 type
>
> ACL entry attribute
>
> Held in entry
> Protects entry's user attributes
> Pending inheritance amendment to
> proposal would add ability to protect
> user attributes of entries in subtree
> of which the entry defining the policy
> is the root
>
> GRANULARITY
>
> X.500: 6 granularity types, many values
>
> Entry
>
> ACI governs access to entire entry
>
> All User types and values
>
> ACI governs access to all values of all "user"
> entry types
>
Correction -> user attribute types
> All User types
>
> ACI governs access to all user types
Clarification . user attribute types
>
> Type
>
> ACI governs access to a specific type
>
> All values
>
> ACI governs access to all values of a
> specific type
>
> Value
>
> ACI governs access to a specific value of a
> specific type
>
> LDAP ACL MODEL DRAFT: 1 granularity type, 4 values
>
> Sensitivity class
>
> Attributes can be grouped into four
> "sensitivity classes"; each sensitivity
> class can have a separate policy.
>
> SUBJECT TYPES
>
> X.500: 5 types
>
> User DN
>
> DN of a user entry
>
> THIS
>
> DN of the entry itself (used only with
> prescriptive ACI)
>
> Group
>
> entry DN of a "group of names" type entry
>
> Subtree
>
> (DN of the root of a subtree; a "chop"
> operator is provided to allow a subject
> to represent an arbitrary prefix of a subtree)
>
> All users
>
> all users
>
> LDAP ACL MODEL DRAFT: 1 type + 2 additional proposed types
>
> DN
>
> DN of:
> user with entry in this directory
> foreign user
> group
To be fair, group should be classified as a separate type as in the X.500 case
> role
>
> (proposed) THIS
>
> DN of the entry itself
>
> (proposed) Everybody
>
> all users
>
> PERMISSIONS
>
> X.500: 12 permissions in 3 categories
>
> usable at any granularity:
>
> Add
> Disclose on error
> Read
> Remove
>
> not usable at Entry granularity:
>
> Compare
> Filter Match
>
> usable ONLY at Entry granularity:
>
> Browse
> Export
> Import
> Modify
> Rename
> Return DN
>
> LDAP ACL MODEL DRAFT: 8 permissions in 1 category
>
> Add
> Delete
> Manage
> Use
> Read
> Write
> Search
> Compare
>
> PRECEDENCE
>
> X.500: Many levels, ACI entry granularity
>
> Each ACI entry has a numeric precedence.
> Different ACI entries in the same directory
> entry or subentry may have different precedences.
> The standard does not define a range for
> precedences, so the number of levels is in principle
> infinite.
>
The standard does define that precedence lies in the range 0-255. Here is the
ASN.1
Precedence ::= INTEGER (0..255)
> LDAP ACL MODEL DRAFT: none
>
> AUTHENTICATION STRENGTH
>
> X.500: 3 levels
>
> Strong
> Simple
> None
>
> (note that these are the X.500 authentication
> mechanism names, NOT the LDAP mechanism
> names).
>
> LDAP ACL MODEL DRAFT: none
>
> Proposers are considering proposals to add
> this function based on the LDAP authentication
> mecahnism names.
>
> DENIAL
>
> X.500: per permission, subject to precedence
>
> each permission may be explicitly granted or denied
>
> denials only override grants at same or lower precedence
>
> LDAP ACL MODEL DRAFT: none
>
> Proposers have agreed to add this function
> based on expressed IETF ldapext working group consensus
> (but still think it's a bad idea!).
>
> ACI MANAGEMENT POLICY INFORMATION
>
> X.500: 2 mechanisms
>
> Entry ACI protects self
>
> this necessarily creates a permission
> propagation problem (which is why it's
> specifically deprecated in the X.500
> documentation)
>
> Prescriptive ACI of superior entry protects
> subordinate entry's ACI
>
> this can create a permission propagation
> problem if superior entry's prescriptive
> ACI entry is also used to grant or deny
> permissions to other, non-ACI attributes.
>
I would appreciate a fuller explanation of this please.
> LDAP ACL MODEL DRAFT: 1 mechanism
>
> separate owner attribute for entry defining ACI
>
> this does not create a permission
> propagation problem
>
> SPECIFICITY
>
> Specificity defines how the access control mechanism determines
> which ACI entries apply to a particular access control decision.
> In the descriptions below, ">" should be read as "is more specific
> than". Presence of a more specific entry prevents evaluation of
> all less specific entries in both X.500 and the LDAP ACL MODEL DRAFT. "="
> should be read as "is exactly as specific as"; equally specific entries
> are all applied (according to defined combinator rules) in both X.500 and
> the LDAP ACL MODEL DRAFT.
>
> X.500: Many specificities in 2 classes
>
> For subjects,
>
> DN = THIS > Group > Subtree > All Users
>
Correct
> For ACI entries,
>
> Entry > All User types and values >
> All User types > Type >
> All values > Value
>
This is wrong. It should say
For attribute types
Type>All user types=All user types and values
For attribute values
Value> All values=All user types and values
> LDAP ACL MODEL DRAFT: 2 specificities in 1 class
>
> For subjects,
>
> Any Collection type > identity
>
> EFFECTIVE POLICY
>
> X.500:
> scope of individual ACI entries is easy to determine
> for Entry ACI and Subentry ACI, but can
> be quite difficult to determine for
> Prescriptive ACI, since scope is based on
> a subentry pattern-match expression which can
> be very complicated
>
> ACI entries applicable to a given data item is
> very difficult to determine, since
> information about which prescriptive ACI
> entries apply to a particular data item
> is not available
>
This was the case, but is no longer, since the 1997 version of X.500 has
defined the accessControlSubentry operational attribute that points to
prescriptive ACI controlling an entry. The definition is repeated below:
The accessControlSubentry operational attribute identifies all access control
subentries that affect the entry. It is available in every entry.
accessControlSubentry ATTRIBUTE ::= {
WITH SYNTAX DistinguishedName
EQUALITY MATCHING RULE distinguishedNameMatch
NO USER MODIFICATION TRUE
USAGE directoryOperation
ID id-oa-accessControlSubentry }
> rules for combining ACI entries are quite complicated
>
> LDAP ACL MODEL DRAFT:
>
> scope of ACL entries is easy to determine in all
> cases (prefix of subtree including root)
>
> source of all ACL policy information is explicitly
> available in all cases
>
> rules for combining ACL entries are simpler than X.500
>
> POLICY ADMINISTRATION SIDE-EFFECTS
>
> X.500
>
> nested groups create policy side-effects by adding
> subjects to one group as a silent consequence
> of adding them to another group
>
But you should note that the X.500 standard specifically states that this need
not be the case, since groups and nested groups should be locally expandable
or the user not given permission. Here is the relevant text from the standard.
ADSA is not required to perform a remote operation to determine whether
the requestor belongs to a particular group for the purposes of Basic
Access Control. If membership in the group cannot be evaluated, the
DSA shall assume that the requestor does not belong to the group if
the ACI item grants the permission sought, and does belong to the
group if it denies the permission sought.
> LDAP ACL MODEL DRAFT:
>
> there are no policy admin side-effects
>
> SUPPORT FOR AUTONOMY AND FEDERATION
>
> X.500
>
> precedence undermines administrative authority
> through lack of support for limiting
> subordinate adminstrators' ability to
> assign higher precedence than superior
> administrators; this allows subordinates
> to override superior's policy
>
This is correct. However, two controls are available to the superior
i) the superior sets the control at precedence 255 and then they cannot be
overwritten (other than deny), or
ii) organisational controls are used to keep subordinates in their place (i.e. let
them go if they dont follow the rules!)
> multiple groups + explicit denial creates an asymmetry
> between administrators of equal authority:
> an administrator who wishes to deny access
> can always override an administrator who
> wishes to grant access regardless of
> the "paper policy" regarding resolution
> of such conflicts
>
> LDAP ACL MODEL DRAFT:
>
> precedence is not supported; superior administrators
> can regulate actions of subordinates through
> management of ACL ownership
>
> explicit denial is not supported, so no asymmetry
> arises between administrators of equal authority
>
> CAUSE AND EFFECT
>
> X.500:
>
> the combination of multiple group memberships,
> explicit denial, multiple ACI entry applicability,
> and precendence makes it very difficult for
> administrators to figure out in advance what the
> effect of making any particular change to ACI
> is going to be.
>
Agreed. THis is why a simpler subset of X.500 would be advisable. I know that
IBM UK are advocating (and perhaps implementing) this via a restricted
administrator interface that limits the amount of ACL setting that the
administrator can do.
> if an ACI entry is added, the consequences may be:
>
> no user's effective access is changed
> all users get more access
> some users get more access
> some users get more access and some less
> some users get less access
> all users get less access
>
> if an ACI entry is deleted, the consequences may be:
>
> no user's effective access is changed
> all users get more access
> some users get more access
> some users get more access and some less
> some users get less access
> all users get less access
>
> to determine which of these has actually occurred,
> the administrator may have to examine every ACI
> entry in the system and run the access decision
> algorithm in his head for each entry whose
> effective policy he wishes to understand.
>
> LDAP ACL MODEL DRAFT:
>
> the absence of explicit denial and precendence
> and the significantly smaller number of
> potentially applicable ACL entries makes it easier
> for administrators to figure out in advance what the
> effect of making any particular change to ACI
> is going to be.
>
> if an ACL entry is added, the consequences may be:
>
> no user's effective access is changed
> all users get more access
> some users get more access
>
> if an ACI entry is deleted, the consequences may be:
>
> no user's effective access is changed
> some users get less access
> all users get less access
>
> to determine which of these has actually occurred,
> the administrator has to examine only the ACL entry
> for the entry whose effective policy he wishes
> to understand and any entries which that entry
> designates as policy sources. He still has to
> run the access decision algorithm in his head,
> but as noted above, it's a simpler algorithm.
>
> REQUIREMENTS COVERAGE
>
> Since the authors of this comparison also produced the
> LDAP ACL MODEL PROPOSAL, it will come as no surprise that
> they think the requirements set forth in "Access Control
> Requirements for LDAP" are well addressed by that proposal.
>
> The requirements which appear to the authors to be unsatisfied
> by the X.500 mechanism are:
>
> U1: "When in doubt, simpler is better"
But you could argue that X.500 satisfies G2 - safer is better.
>
> The text of the comparison above in our opinion
> substantially supports this conclusion.
>
> U17: "Administrator MUST be able to determine where inherited
> policy information comes from, that is, where
> ACLs are located and which ACLs were applied"
>
> Prescriptive ACI does not satisfy this requirement
> (hence the suggestion to use inherited ACLs
> rather than prescriptive ACI with pattern matching
> for LDAP)
>
This is wrong as I pointed out above.
> U6: "Management of access to resources in an entire subtree
> SHOULD require only one ACL"
>
> This is quite difficult to achieve while preserving
> reasonable attribute granularity with prescriptive
> ACI, because supported granularities are keyed only
> to entries and attribute types. Hence when new
> schema types are added via dynamic schema mechanisms,
> all ACI entries which need to be applied to entries
> adopting the new schema types need to be changed.
However, in X.500 you can have a ACL that controls "all attribute types and
values", and this will control all new schema changes.
> The LDAP ACL MODEL PROPOSAL's grouping by sensitivity
> class makes this much simpler.
>
> U7: "Override of subtree policy MUST be supported on a per-
> directory entry basis"
>
> This is very difficult to ensure, because of
> uncertainty about precendce values of prescriptive
> ACI which will be applied to given entries
> and because deny at Subtree granularity overrides grant
> at Entry granularity within equal precedence through
> asymmetry.
I dont follow this. There is no uncertainty about precedence values since these
are explicit in the prescriptive ACI. Therefore an entry can always increase
precedence by 1 (unless absolute deny was set by the administrator at the
subentry level, and clearly this should not be over-ridden)
>
> U12: "It MUST be possible to review 'effective access' of
> any user, group, or role to any entry's attributes."
>
> X.500 leaves this explicitly as the responsibility
> of the GUI. The LDAP ACL MODEL PROPOSAL provides
> a protocol mechanism for retrieving effective access
> information.
>
X.500 provides protocol support for retreiving ModifyRights, and Read rights can
be determined by "suck it and see". SO protocol support is sort of provided,
although I agree it is not optimum.
> The absence of support for effective policy review
> makes the authors question whether G3 ("ACL administration
> SHOULD be part of the LDAP protocol") can be
> satisfied in any meaningful way. Normal programmatic
> and command-line ACL administration actions such as
> analogs of the UNIX
>
> chmod o+r foo
>
> are almost impossible to support at a protocol level
> if the X.500 model is used, because of the difficulty
> of discovering what effective permissions "r" is to
> be added to and what entry needs to be changed to
> add it (without traversing the entire directory structure
> and performing a complicated effective access
> computation).
>
> FINAL NOTES
>
> X.500 supports a "simplified mechanism". The principal
> simplification is the removal of Entry ACI. The remaining
> system is still very much more complex than the LDAP ACL MODEL
> PROPOSAL.
>
Correction. THe simplified model also removes inner areas and the ability to
delegate authority to a subordinate subtree. ACLs can only be applied to the
subentries of the root (autonomous admin point).
I hope you found these notes useful
David
> ============================================================
>
> This comparison was produced by Bob Blakley, Debora Byrne, and Ellen
> Stokes of IBM.
>
> --bob
>
> Bob Blakley
> IBM Lead Security Architect
> Voice: +1 (512) 838-8133
> Fax: +1 (512) 838-0156
> Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
> Internet: blakley@us.ibm.com
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************