Re: ACL Model and application defined permission

["Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>]

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.
    

Rob Byrne wrote:
> 
> Bruce Greenblatt wrote:
> >
> > 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
> 
> 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.
> 
> > 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
> 
> 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.
> 
> > 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

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|