Give ACL based on an LDAP filter
Give ACL based on an LDAP filter
The point is to be able to automagically give ACL rights on a department to its manager.
Using a filter like (&(objectClass=organizationalUnit)(manager=%dn%)) as target for an ACL assignment would answer this problem
Activity
changed milestone to %FusionDirectory 1.4
By Côme Chilliet on 2018-01-10T15:05:21 (imported from GitLab)
added PJ1802-0188 label
By bmortier on 2018-04-05T09:03:32 (imported from GitLab)
changed milestone to %FusionDirectory 1.5
By Côme Chilliet on 2019-02-25T12:39:19 (imported from GitLab)
changed milestone to %FusionDirectory 1.4
By bmortier on 2019-09-26T08:24:51 (imported from GitLab)
It seems we do have a non-documented feature for assigning ACLs by filter, but the other way around: It allows to give ACLs to users matching a given filter. This seems less useful to me, because the filter is fixed. It can be useful in cases where you may want to filter users on something else than group/role, like (eduPersonAffiliation=student) to assign ACL to all students for instance.
It would need to be added back to the UI and tested.
What I had in mind was to give rights on things referring the logged in user, using a filter with the user dn.
Having both would prove quite powerful. Only left limitations would be inability to use this on group. (Use a filter to select which groups have rights and an other to select on what).
I intend to resolve all filters when loading ACLs, which means the ACLs would not change until logout, even if the LDAP value which gave the rights changed (like someone removed the student value from eduPersonAffiliation). This feels OK to me since this is already the case for ACLs assignments and sessions are not supposed to last several days.
User filter will be resolved on the user node directly so it should not eat time/resources, target filter will be searched for on the ACL assignment base sutree, so these ones should be kept simple and not return too much results. (like, giving rights on (eduPersonAffiliation=student) as target to be able to edit all students is a bad idea because there might be lots of them. We may test this to be sure of the performance)
By Côme Chilliet on 2019-10-02T13:16:09 (imported from GitLab)
mentioned in commit 7cf8e8bb
By Côme Chilliet on 2019-10-02T15:01:53 (imported from GitLab)
mentioned in commit 48dbad45
By Côme Chilliet on 2019-10-02T15:01:54 (imported from GitLab)
mentioned in commit 05fe5376
By Côme Chilliet on 2019-10-02T15:01:54 (imported from GitLab)
mentioned in commit 484cd56e
By Côme Chilliet on 2019-10-02T15:01:54 (imported from GitLab)
mentioned in commit 2291c070
By Côme Chilliet on 2019-10-02T15:05:40 (imported from GitLab)
mentioned in commit 4067bf36
By Côme Chilliet on 2019-10-03T09:26:35 (imported from GitLab)
So, I had misunderstood the GOsa feature and it was in fact a target filter in the end. Well, I saw that too late so we have the two features now anyway, target filter and user filter.
I tested the common usecase (manager=%dn%) and it works well. We’ll need to test performance when too many match the filter, and probably add an error at login in this case (when more than sizelimit are matching). Maybe also some explanation in the ACL edition form.
By Côme Chilliet on 2019-10-03T09:35:09 (imported from GitLab)
