Subject: ACL Model and application defined permission

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 14 Feb 2001 17:33:17 -0800

As I understand it, in the current ACL Model draft, the kinds of 
permissions that an LDAP server understands are limited to those defined in 
clause 4.1.1.  Is this accurate?  The reason that I ask, is that I would 
like to store application defined permissions as well.  For example, I have 
an application the allows users to perform several different actions on 
various types of objects.  Let's call these objects foo objects, and the 
actions foo-1 through foo-n.  None of these correspond to the add, delete, 
export, etc. permissions defined in clause 4.1.1.  I would like to be able 
to have a ACI assigned to an entry that represents a foo object that grants 
permissions to perform some foo-i actions to some list of subject entries 
(i.e. users, groups, organizationalUnits, domainContexts, etc.).  Can I 
grant these permissions with the mechanisms currently defined in the ACL 
Model draft.  My presumption is that this would require a new permission 
level, but I don't see how to shoe-horn this in to the BNF of 4.1.1 or the 
ASN.1 of 4.1.2.

I would also like to be able to verify that a subject entry has the 
appropriate rights to perform an operation against a specified object.  How 
is this supposed to work in the existing model?  Either the effective 
rights control or extended operation ought to be able to work for this, but 
the definitions are confusing to me.  There should be a new clause 11.1.4 
that gives a specific example of a Search request with the control that 
shows how to do permission verification.  Similarly, there should be a new 
clause 12.2 that gives a specific example of the use of the extended 
operation.  I'd note that in both of these cases, there ought to be a way 
for the LDAP client to list out the permissions in which it is interested.

I'd also like to be able to find all of the entries in a specified scope to 
which a specified user has permission to perform action foo.  I'm guessing 
that I'm supposed to use the effective rights control for this, but without 
the example, I'm at a loss as to how to build the search and the control 
appropriately.

Overall, the model appears to be very close to meeting the requirements for 
application defined permissions.

Thanks,

Bruce Greenblatt

---

From: Rob Byrne <[email-masked]>
Date: Thu, 15 Feb 2001 15:19:03 +0100

> clause 4.1.1.  Is this accurate?  The reason that I ask, is that I would

Hi Bruce,

That's the way it's written right now.  I agree that the idea of having
an extensible access control model is very attractive.  The reason is
that we could all then be legitimately claim to be running version 1.0,
say, of the LDAP access control model...but with our own little tweaks. 
It would also hopefully allow writers of new LDAP extended operations
and controls to define the required permissions for their new stuff
without having to ramp the version number of the LDAP access control
model.  I started to work on this idea but haven't had time to get it in
a reviewable state...basically the idea would be to allow the permission
list to be extended and in addition to allow an extended permission to
have some "extended fields" associated with it which would contain any
data that the permission required.  The problem is of course, what
happens if you send an aci with extended stuff to another server that
doesn't support it...reject it...? OK, but that's a big pain for
replication...Ok, publish the "supported extended permissions" in the
rootDSE and make it part of the replication agreement that both servers
check they support the same stuff...I'm just giving you an idea of the
things we need to think about to get an extensible model to work.  It's
conceivable that it would be too much work for this pass of the draft.

> the definitions are confusing to me.  There should be a new clause 11.1.4

Agree 100%...I started working on clarifying these...again...not done.
I think I agree with the spirit of what you want to do here but I don't
think for example you need to be able to specify the action "foo" when
you ask for the effective rights...I think it's easier to specify the
user, the object and get all the rights back--the requestor can then
check to see if "foo" happens to be in there.  Anyway, that's kind of a
detail.
One thing I was hoping to do was drop the extended operation entirely
and just have the control...I think you can do everything you want with
a control if you get it right.

Rob.

---

From: "Larry S. Bartz" <[email-masked]>
Date: Thu, 15 Feb 2001 12:00:29 -0500

The early ACL Model drafts proposed to support a functionality similar
to what Bruce describes. The ACL element was called "use", and was meant
to provide an indication of authorization to access or exercise the
targeted object or resource.

Subsequent discussions in ldapext revealed objections. Some argued
that the issue was simply out of scope, that the model should focus
solely on Directory operations. Others asserted that attempting to
support such functionality in the ACL Model amounted to the first
step down a slippery slope of extreme complexity.      

Consensus (at that time) resolved that the ACL Model should be limited
to supporting Directory operations. As a consequence, the "use" term and
its intended functionality disappeared from the ACL Model drafts.

This is a Good Thing. The ACL Model should be limited to support of
Directory operations. This is not to say that the Directory shouldn't 
be involved in supporting access, authorization, and usage decisions for
entities which are external to the Directory.  

Analysis in other venues (such as DMTF's CIM and IETF's Policy WG)
has revealed that authorization is a much larger question than can be
supported by a binary "go/no-go" indicator. Network resources,
distributed
objects, and applications require a richer information model.

The Directory is the place to do it, but the ACL Model is not the
way to do it. Policy is the way to go.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 15 Feb 2001 09:40:43 -0800

>conceivable that it would be too much work for this pass of the draft.

Thanks for the thoughtful response.  I think that a simple extension to the 
existing BNF/ASN.1 could support this.  As long as it is kept simple, there 
would be no reason for this to be a "real extension" that needs to be 
published in the rootDSE.  All server would have to support the application 
defined permissions, just as much as they support the read, write, etc. 
permissions that are defined in the current model.  I will write up a 
proposal today, and send it out.  This feature would be of enormous value 
to builders of LDAP enabled applications.  The notions of groups, aliases, 
organizational units, etc. are very powerful mechanisms, and being able to 
combine them with rights evaluation is an extremely compelling feature that 
is not available elsewhere.

Bruce

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 15 Feb 2001 09:44:05 -0800

At 12:00 PM 2/15/2001 -0500, Larry S. Bartz wrote:

>The ACL Model should be limited to support of

Larry,

I couldn't disagree more.  What you fail to mention, is that ALL entities 
are external to the directory.  The information that is stored in the 
directory is a partial representation of an external entity.  For example, 
there are many more attributes of a user than are stored in the 
directory.  Why are users, organizations, file servers, etc. internal to a 
directory, and a book or a hat external to the directory?  There is no 
obvious reason, because the directory is just keeping track certain 
properties of these entities.  The more information that is kept in the 
directory,the more valuable it is.

Bruce

---

From: "Larry S. Bartz" <[email-masked]>
Date: Thu, 15 Feb 2001 14:11:11 -0500

> directory,the more valuable it is.

Bruce,

I agree with your assertion regarding the difference between an object
and the representation of an object in the Directory. My bad. I
shouldn't 
have used a double negative in the sentence which you quoted above.
Restated,
"The Directory should be involved in supporting access, authorization,
and
usage decisions for entities which are external to the Directory." We
agree to that, I think.

I also agree that the value of the Directory is proportional to the 
information it contains. Further, I agree that the Directory is a
natural
platform for associating principals and services, consumers and
suppliers,
for convenience and/or in support of security goals.

I disagree with your suggestion that the scope of the ACL Model should
be extended. 
 
The ACL is the place to manage access to the Directory representation, 
the motes of data which comprise the Directory itself. The ACL Model is
scoped to manage access of Directory operations, Directory CRUD. The ACL
Model should stay in scope.

This very issue was discussed by several participants in ldapext in the 
spring and summer of 1998, and maybe again later. The discussion was 
initiated by those who objected to the "use" term (and its intended
functionality) of the original and early ACL Model drafts. The outcome,
the result of those discussions, was the focused and purposeful scope of
the current ACL Model.  

Users, organizations, file servers, books, hats, and whatever else can
be represented in the Directory, but they are not a part of the ACL
Model. 

By the same token, Policies (which can include authorization policies)
which apply to certain entities can also be represented in the
Directory.
As proof, see the work products of the Policy WG and the work products
of
DMTF CIM. These Policies should not be part of the ACL Model.

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 15 Feb 2001 12:10:12 -0800

At 02:11 PM 2/15/2001 -0500, Larry S. Bartz wrote:

OK.  We agree on something.  That's always good.

>the result of those discussions, was the focused and purposeful scope of

As I recall, the original draft of the model generated much unconstructive 
disagreement, and the chairs called for a vote on whether the work should 
even continue.  As a result of the vote, the original model was 
pitched.  The "use" construct defined there was not the same as what I am 
proposing.  From the archives:

"Use - Execute; useful in controlling access to the objects referred to by 
directory entries than in controlling access to the directory entries 
themselves." (from draft-ietf-ldapext-acl-model-00.txt)

Clearly this is not the same as application defined permissions.  I have 
been following this issue from the beginning, and I don't ever remember a 
discussion specifically related to application defined permissions taking 
place on the list.  Of course there used to be a participant on the mailing 
list whose postings I stopped reading (list historians can probably guess 
who this is), so it is possible that I missed it.

Bruce

Bruce Greenblatt

---

From: Rob Byrne <[email-masked]>
Date: Fri, 16 Feb 2001 12:34:57 +0100

Larry,

I think you are absolutely right that the access control model must stay
focused and that there will be "other policy" that will be quite rightly
expressed external to the access control model.  I just want to clarify
that the kind of extensiblity I was talking about trying to define is
motivated by the need to support evolving directory "stuff" and so I
think is in scope.
The point is that it seems a shame not to be able to incorporate new
controls or extended operations, as much as we can, within one access
control model.  A good example would be the Proxy Authorisation
Control.  Classically an access control statement makes an assertion
about the rights of some subject on an object--so there are two
important "bits".  Along comes the Proxy Control and now there ia an
extra bit, namely the other subject that the original subject can proxy
as.  So unless the original model provides a way to extend itslef to
accomodate the new subject, it has to be redone.  If we can design a
model to allow this kind of extensibility then I think that is
desirable--there will always be new controls/extended operations coming
along.
In relation to Bruce's issue, I guesss what you would dislike would be
if Bruce used this mechanism to say define a new extended permission
"sitOn" and then represented a chair as cn=brucesChair,o=chezBruce and
then started granting and denying access using this permission and
object in the obvious way.  I kind of see both sides here--"sitOn"
clearly has nothing to do with a directory operation and so is therefore
out of place as a permission....on the other hand if an application
wanted to leverage the directory's support for notions of user, objects
and permissions...then why not...?  We haven't explicitly included that
in the model...it's just allowed by it.

Rob.

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 16 Feb 2001 09:25:21 -0500

Thanks, Rob.

You have succinctly summarized my position and explained the
extensibility
strategy to my satisfaction.