[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on the ACL Model draft
Ryan and Rick,
My responses are embedded and prefaced by (EJS). Some of your
comments have been delete in this email and will be addressed in a
separate email.
Ellen
At 01:51 PM 3/16/00 -0500, Richard V Huber wrote:
This is a joint set of comments from Ryan Moats and Rick Huber. We've
been discussing them internally for a while, so they may repeat some of
the last day's discussion on the list, but there is a fair amount of new
material here.
Rick Huber
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Page 3
TECHNICAL:
No mechanisms are defined in this document to control
access to access control information or for storage of
access control information at the server; this is vendor
dependent.
But the ACIs are attributes. Don't the normal access controls
described in the rest of the draft apply here?
(EJS) No. This was an agreement several ldapext meetings ago that
this was out of scope. Please also see section 6.4 first paragraph that
states: "Policy ownership controls administrative subdomains. It
can also control who has permission to set / change acls
for implementations that do not have ACI controlling
access to itself. ... "
EDITORIAL: Add reference to ACL Requirements document in last paragraph.
(EJS) Will do, may need to add at or during last call because although the
ACL requirements doc has been approved for RFC publication, it hasn't been
published yet so I don't have the RFC number.
Page 5:
EDITORIAL:
A "subject' is an entity which initiate actions in an
^ ^^^^^^^^
information system.
The quotes on subject don't match. Also, "initiate" should be either
"may initiate" or "initiates".
(EJS) Will do - I'll use the word 'initiates'.
Page 7:
EDITORIAL: Add Section number at end of last paragraph.
(EJS) Will do.
Page 9:
EDITORIAL:
aCIMechanisms lists the values (list of OIDs) that
defines the access control mechanism in effect for the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
scope of that subschema entry. More than one mechanism
may be in effect for the scope of that subschema entry.
Should be "define the access control mechanisms" since it explicitly notes
that there can be more than one.
(EJS) Will do.
EDITORIAL:
The intent of the following attribute definitions is to
design a common interchange format. Any given LDAP
server should be able to translate the below defined
attributes into a meaningful operation requests. Each
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
server should be able to understand the attributes; there
should not be any ambiguity into what any part of the
syntax means.
Should be "into meaningful operation requests" (drop the "a").
(EJS) Will do.
EDITORIAL: quote mismatch and add section number in second to last
paragraph.
(EJS) Will do.
Page 10:
EDITORIAL:
Two attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation. These attributes are used in typical
LDAP APIs and in LDIF output of ACI. These two attributes
may be queried or set on all directory objects: ldapACI
and policyOwner. Their BNF and definitions are defined
^^^^^^^
below.
Should be "given" or "presented".
(EJS) Will do.
Page 14:
TECHNICAL:
<attr> describes either an attribute name or an attribute
collection. The keyword attribute indicates that the
following printable string refers to an attribute name.
If the string refers to an attribute not defined in the
given server's schema, the server SHOULD report an error.
The keyword "collection" indicates that the string that
follows describes a group of attributes. The method for
^^^^^^^^^^^^^^
grouping attributes is server specific. Another option
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for the collection printable string is "[entry]". This is ...
This seems to say that no ACI containing an attribute collection can be
portable between vendors' LDAP products. Since attribute grouping may
well be common (if you have a number of attributes that are always
treated the same way for access control) this seems to be a major
interoperability problem.
Wouldn't it be better to require that the wire protocol list all the
attributes and leave collections as a shortcut that some vendors'
products may use in their administrative interface? Note we do not
object to "[all]" and "[entry]" since they are well defined, we just
have a problem with the server specific collections.
(EJS) See my previous email on this topic...
Page 15:
TECHNICAL:
means that this group (Dept XYZ) is granted permission to
read and search all attributes except attr1 because attr1
is more specific than "[all]".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What if it were two collections rather than specific attribute vs. [all]?
How do you determine which is "more specific"?
(EJS) Collection is more specific than All. Collections are server defined,
so it is possible, but not probable, for an attribute to be a member of both
collections. The specificity would be server defined. Also, keep in mind
that I'm soliciting input on whether to keep or remove 'collection' - we'll do
whatever is the consensus.
TECHNICAL:
More specific policies must override less specific ones
(e.g. individual user entry in ACI takes precedence over
^^^^
group entry).
The "e.g." makes us very nervous. There needs to be a solid definition
of what "more specific" means to avoid problems of interpretation by
different developers. (EJS) I'll tighten up the text for specificity and
so explanation is not just implied by example.
Also, what would happen if a DN was a member of
two groups, where one had rights while the other did not? An example
on page 20 says to take the union of rights, but this behavior should
be specifically defined in the text, not just in an example. Are union
semantics always used for dnTypes at the same precedence?
(EJS) yes.
TECHNICAL:
Deny takes precedence over Grant. When there are
conflicting ACI values, deny takes precedence over grant.
Deny is the default when there is no access control
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
information.
^^^^^^^^^^^
Does this mean that in the absence of any ACI at all, there is no
access to anything?
(EJS) Yes, this was discussed on the list several weeks ago and
was the consensus of the group.
Does it imply that there MUST be an ldapACI at the
root, since root can't inherit and without an explicit ldapACI there
will be no access at all?
(EJS) There does not have to be a ldapACI at the root or even a default
ldapACI. Root could inherit from a default, but that is implementation
defined. And without an explicit ldapACI at the root, there is not access
(which was consensus).
Page 16:
TECHNICAL:
Precedence of Privilege Attribute dnTypes within a scope
(highest to lowest):
- ipAddress
^^^^^^^^^
- access-id, kerberosID (both same precedence)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- group
- role
- subtree
Requirement S6 of the requirements draft states:
S6. Access policy SHOULD NOT be expressed in terms of
attributes which are easily forged (e.g. IP addresses).
There may be valid reasons for enabling access based on
attributes that are easily forged and the
behavior/implications of doing that should be documented.
Isn't use of ipAddress flaunting this?
(EJS) Not really. The requirements document was put in place to serve
as a guideline for writing the model draft, not as an explicit 'must follow'
for writing the draft. So some things in the requirements are not in the
draft and vice-versa. This was explained at previous ldapext meeting.
Just because ipAddress is in the draft and an implementation provides it,
doesn't mean that the deployment of the server needs to use it.
According to our reading of the definition of "access identity" in
Section 3, a Kerberos ID would BE an access identity. Why make a
distinction here?
(EJS) Syntax. access-ID is a DN, kerberosID is typically something like
userID@realm. Also, recall here, that there is pending email on generalizing
kerberosID.
TECHNICAL:
"deny" takes precedence over "grant", but groups have precedence over
roles. What happens if a permission is granted to a subject by virtue
of group membership but denied by virtue of role membership?
(EJS) Let's answer when we settle on precedence of groups and roles.
What is the precedence among precedence groupings?
(EJS) If I understand the question correctly, none; union semantics would
apply and deny takes precedence over grant when both are listed.
Page 18:
EDITORIAL:
6.5.2 Modifying the ldapACI Values
Modify-Replace works as defined in the ldap oepration
^^^^^^^^^
modify. If the attribute value does not exist, create the
value. If the attribute does exist, replace the value. If
the ldapACI value is replaced, all ldapACI values are
replaced.
Spelling.
(EJS) Will do.
Page 20:
TECHNICAL:
Examples are useful and should be encouraged, but they should not be
the sole source of parts of the specification. Example #2 is the only
place we have found that says that ACI is combined when two dnTypes
have the same precendence. And the fact that the combination is by
union is not stated anywhere, though it can be inferred from the
example.
(EJS) We'll explicitly state union and intersection semantics so as
not to infer from examples.
Page 25:
EDITORIAL:
dnType speficies the type of subject security attribute.
^^^^^^^^^
Defined types are specified in the BNF.
Spelling.
(EJS) Will do.
Page 31:
TECHNICAL:
Should the security considerations section include some mention of the
special problems that might arise in a replicated environment? What
happens when new entries or attributes arrive at a replicated server
out of sequence with the arrival of associated ldapACI data?
(EJS) I suggest that at a future time there be a draft that discusses the
interaction of access control with other directory functions/features. In the
case of replication, perhaps we should look at adding this to one of the
(many) ldup drafts. I'll put this on my list to discuss since I author an
ldup draft.