[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
X.500 vs. LDAP ACL MODEL PROPOSAL comparison
All,
(Warning: this is a long note)
We've finished our comparison of the LDAP ACL MODEL PROPOSAL
and the X.500 ACL mechanism.
Those of you who are evaluating your responses to Tim's note
may find this information useful in evaluating the functionality
supported by the two mechanisms and the complexity required to
implement and manage each mechanism.
We believe you'll find as you read through the comparison
that the X.500 mechanism supports a much more complex and
expressive policy language than the LDAP ACL MODEL PROPOSAL
but at the cost of very signficantly more implementation and
administrative complexity.
We'd welcome any comments on this comparison, and will incorporate
improvements into the text and reissue it as appropriate.
Here's the comparison:
============================================================
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.
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
Protects entry's subentries
Not applicable to entries except that in which
defined
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
All User types
ACI governs access to all user 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
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.
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.
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
For ACI entries,
Entry > All User types and values >
All User types > Type >
All values > Value
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
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
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
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.
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"
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)
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.
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.
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.
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.
============================================================
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