Subject: application defined permission

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 07 Mar 2001 11:51:41 -0800

After discussions on the list, and private discussions with Rob Byrne, here 
is a slightly modified proposal.  There was some discussion of using a 
separate attribute type name to hold application defined permissions.  I 
didn't put that in the modified proposal, but I'm OK with doing that, even 
though it doesn't seem to make much difference.  I also got several 
questions about why couldn't you just map application defined permissions 
into the existing permissions defined in the ACL model.  Just because you 
are giving a user the right to do something in an application does not 
necessarily mean that you want to give that user any rights to read or 
modify the entry in the directory that represents that application.

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Rob Byrne <[email-masked]>
Date: Fri, 09 Mar 2001 16:52:36 +0100

Bruce,

My own feeling is still that it would be better to leave application
stuff out of the core model.  I would love to hear some more more
opinions on this.

In terms of your proposal...I like the tagged oid approach.  I think it
would be better if you did not mention the xep stuff at all--let's leave
that for the next guy who will struggle with the extended operational
permissions....if that ever happens.

Point taken on the overloading effects of the interpretation approach. 
Though by just using searchish permissions (read, search,
browseDN,returnDN), the effect of this could be minimised ie. at least
the users could not change anything.

Rob.

Bruce Greenblatt wrote:
>   ------------------------------------------------------------------------
> 
>    application-defined-aci.txtName: application-defined-aci.txt
>                               Type: Plain Text (text/plain)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Mar 2001 08:50:59 -0800

At 04:52 PM 3/9/01 +0100, Rob Byrne wrote:
>stuff out of the core model.

I concur.  The ACL model should be simple.  This would add
unnecessary complexity to the specification and implementations.

>the users could not change anything.

In OpenLDAP, our approach is to use permissions governing core
LDAP operations to govern extended operations.

For example, when LDAP Modify Password Extended Operation is
configured to update a directory attribute, we require "write"
permissions on that attribute.

If our implementation of StartTLS were dependent on read of
directory attribute (such as one holding a certificate), we'd
require "read" on that attribute.

We also use "psuedo" attributes (which don't actually exist)
to govern access to information not held in any attributes.

We also govern operations extended by control in a like manner.
For example, we require no special permission to use ManageDsaIt,
but we do require "read" access to the attributes returned due to
presence of the control.

That is, we have "operational experience" which shows that
"extended operation permissions" may not be necessary and can
be left out for now.

---

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 09 Mar 2001 09:01:39 -0800

>unnecessary complexity to the specification and implementations.

I don't really see how the proposal that I made is that complex.  You are 
just adding an extra possibility that doesn't restrict the operations of 
the directory in any way.  If the LDAP server chooses to implement the 
application defined permissions (which it doesn't have to), then in 
calculating the effective rights the application defined permissions should 
be taken into account.  This seems pretty simple to me.  I was never trying 
to say that all LDAP servers had to implement this.  If you don't want to 
implement application defined permissions, don't do it.  It's just one 
other option for implementors.

I think that limiting the list of permissions to those specifically defined 
in the acl model document is opening the door for the possibility of 
problems down the road.  By building in extensibility, you are making sure 
that the protocol and model won't be broken down the road.

>to govern access to information not held in any attributes.

Are you proposing this as a mechanism to implement application defined 
permissions?  I don't understand this.  You give a user the ability to 
write to an attribute that doesn't exist, so that when the user tries to 
write a value into the attribute, the operation fails?  Can you give more 
details?

Thanks... Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Mar 2001 10:08:35 -0800

At 09:01 AM 3/9/01 -0800, Bruce Greenblatt wrote:
>I don't really see how the proposal that I made is that complex.

How does a client determine if the server implements a particular
ACM extension?

I thought we had previously discussed how ACM updates/extensions would
be handled and reached some consensus on the issue.  I was under the
impression that if the syntax needed to be updated, a new syntax would
be defined.  This allows use of existing schema discovery mechanisms
to determine which syntaxes are supported.  However, if the syntax
itself is extensible, the model must support a means for discovering
how the syntax might have been extended.  This, in my opinion, is a
completely unnecessary complication.

>You are just adding an extra possibility that doesn't restrict the operations of the directory in any way.  If the LDAP server chooses to implement the application defined permissions (which it doesn't have to), then in calculating the effective rights the application defined permissions should be taken into account.  This seems pretty simple to me.  I was never trying to say that all LDAP servers had to implement this.  If you don't want to implement application defined permissions, don't do it.  It's just one other option for implementors.
>
>I think that limiting the list of permissions to those specifically defined in the acl model document is opening the door for the possibility of problems down the road.  By building in extensibility, you are making sure that the protocol and model won't be broken down the road.

Adding extensibility requires more than a simple syntax sugar.

>Are you proposing this as a mechanism to implement application defined permissions?

This comment was in the context of extended operation permissions
but may apply to application defined permissions as well.  However,
the point was secondary.  The primary point was that permissions
governing extended operations can be specified in terms of access
upon directory information.  This is a viable alternative to
to specific extended operation access information.

Kurt