Pierangelo Masarati ando@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.
Use case:
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.