Pierangelo Masarati <ando(a)sys-net.it> writes:
I disagree: by running an internal operation with dgIdentity, and
returning the results of that operation, you'd break the security model
of OpenLDAP. In fact, a dynamic group can unveal data that would
otherwise be inaccessible to a user.
This is *exactly* the behavior that Stanford needs, so please make sure
that this is still possible.
Privileges are represented in the directory via entitlements; in other
words, a given user has a multivalued attribute in their directory
record that contains the entitlements that user has.
Applications need to be allowed to verify, for authorization purposes,
that a given user has a given entitlement, but which applications can
see which entitlements needs to vary on an entitlement-by-entitlement
basis (for example, some entitlements may represent data protected by
FERPA, the US student information privacy act).
We want to add regular groups to the directory (rather than using compare
tests against the entitlement attribute) because we can put separate ACLs
on each group and then lock down access to the entitlement attribute
entirely. Otherwise, we end up with a ton of substring ACLs on the
entitlement attribute, which is a performance and maintenance problem.
So, that behavior of letting the dynlist or dyngroup overlay do a query
that the user querying the group tree is not themselves permitted to make
is exactly what we need, since we can then use the more granular access
control possible on the separate group dns to implement control over
entitlement visibility that's otherwise annoying to represent.
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>