Re: application defined permissions

[Rob Byrne <Robert.Byrne@france.Sun.COM>]

Bruce,

I agree with the responses...I think there needs to be a way to
distinguish these "application/user" extended permissions from
"operational" extended permissions, which we may wish to add to the
model later.  At first I thought we could get away with one extension
mechanism for permissions, but the fact that the server can always
ignore your extended application permissions means this is not
possible.  As this means building support for these application extended
permissions explicitly into the model I'm not so warm to the idea.  The
reason, from the implementor point of view is, it's hard enough to get
the core operational access control right without having to worry about
stuff not strictly necessary  to the core.
So my suggestion would be as follows.  Well this is an application
issue.  Even if the application is allowed define it's own permissions,
it still has to define (extenally to the directory) which entries and
attributes these permissions apply to.  So, why not have the application
use existing permissions (after all there is a whole slew of them) on
special entries and attributes that the application defines and
interpret these in a way meaningful to the application ?  For example
instead of requiring the extended application permission "sitOn" to the
entry "cn=brucesChair,o=chezBruce", the application could require the
"r" permission to this entry and interpret that as "sitOn".  Granted,
that involves the application in another mapping task but it can still
leverage the getEffectiveRights control, which seems to be your main
motivation.

Rob.

Rolf.Maeule@varetis.de wrote:
> 
> > Bruce Greenblatt wrote at 21.02.01 01:48:
> >
> > At 11:17 AM 2/20/2001 -0800, Kurt D. Zeilenga wrote:
> >
> > >Because a directory implementation may not implement the operational
> > >usage but your application should still be able to store the user
> > >value.  A server which does not support the operational usage should
> > >not publish the ldapACI attribute in its subschema.
> >
> > I think that the application defined permissions are only useful in an
> LDAP
> > server that already implements the rest of the ACL model.  It is
> important
> > that the effective rights computation for application defined permissions
> 
> > take place in the same manner as the LDAP defined permissions.  If the
> LDAP
> > server is not implementing the operational usage and effective rights
> > computation, it is unlikely to be able to implement the computation for
> > application defined permissions.  I don't ever see an implementation
> > supporting only application defined permissions.  If all an application
> > needs is a place to store permissions, it can easily use the member
> > attribute, or something analogous.  IMHO, the important thing is the
> > ability of the LDAP server to compute effective rights.
> 
> I agree.
> 
> > So, I'd like to
> > see the application defined permissions bundled into the same attribute
> as
> > the other permissions.  However, if the consensus of the WG is to create
> > two separate operational attributes, and have the exact same effective
> > rights operations and controls applying to each attribute, we could
> > probably do it that way.
> >
> > Bruce
> 
> I see two kinds of extensions:
> 
> a) additional rights needed for LDAP operations. A right like "return
> temporary DN which is valid for 5 minutes" might even influence standard
> LDAP operations. You need to modify the LDAP server to support it.
> 
> b) additional rights needed by applications etc. Such rights will never
> influence server implementation.
> 
> An LDAP server might want to reject extensions of type a) or at least say
> "Warning: I do not understand this extension", but accept extensions of
> type b).  I therefore suggest using two attributes.
> 
> Rolf