[Fedora-directory-users] filtered roles' base DN

[Pete Rowley]

> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com 
> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf 
> Of George Holbert
> Sent: Tuesday, August 23, 2005 2:11 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: [Fedora-directory-users] filtered roles' base DN
> 
> Is there any way to give a filtered role an alternate base 
> DN?  It seems like the search scope for filtered roles is 
> limited to the container in which it's created.  

There is no way to do that.  There _used_ to be a way (very early on) to
specify a base dn for class of service - until it was pointed out that there
were security issues with that.  Similar security issues arise with roles
e.g. it would be possible to assign roles across administrative boundaries
i.e. actually effecting the data returned for the entries despite having no
permission to do so.  This is really an artifact of the virtual nature of
the attribute, access control scoping, and performance considerations for
making a projected role secure.  The problem is quite unlike groups, which
have no effect on the entries themselves.

> This means a 
> role created in "cn=roles,dc=example,dc=com" will not apply 
> to entries in "ou=people,dc=example,dc=com".  Is the only 
> solution to create the role above the ou=people container?

In fact, to replicate the scope you require you would add the role as a
child of ou=people (the scope is from the parent of the role configuration).
This has its advantages e.g. the scope of a role is obvious from its
position in the dit; any replication or migration of the subtree would
include the role configuration too, it is much easier to delegate
adminstrative rights over roles across the organization etc.  Unlike group
entries, role configuration entries are not returned by searches that do not
specifically look for them (you need a filter that include
objectclass=ldapsubentry to return them) so there is less need to allow a
different scope.