[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL Model and application defined permission

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.  

"Larry S. Bartz" wrote:
> 
> Bruce Greenblatt wrote:
> >
> > At 12:00 PM 2/15/2001 -0500, Larry S. Bartz wrote:
> >
> > >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.
> > >
> >
> > 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
> >
> 
> 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.
> 
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # 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                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|