Hi list members,
I use a openldap server for the user management of an proprietary client/server application.
Users are modified person class objects.
Groups are groupOfName objects.
Rights are also groupOfNames.
Users are members of groups and groups are members of rights.
To exemplify my problem:
User: cn=example,ou=users,dc=mydomain
Group: cn=supervisors,ou=groups,dc=mydomain
Right: cn=someRight,ou=rights,dc=mydomain
For instance someRight should give all members of supervisors the right to modify other users.
At the moment the ACL is related to the group.
Access to dn.sub="ou=users,dc=mydomain"
By group.exact="cn=supervisor,ou=groups,dc=mydomain" write
By self read
To use the rights I'd need an ACL with a group of group.
Access to dn.sub="ou=users,dc=mydomain"
By group.exact="cn=someRight,ou=rights,dc=mydomain" write
Should allow all members of all groups that are member of someRight to modify users.
Is this possible or is groupOfNames the wrong class to represent group rights?
Thanks in advance!
Jan
On 14/11/2009 11:15, Jan Thiemo Fricke wrote:
Hi list members,
I use a openldap server for the user management of an proprietary client/server application.
Users are modified person class objects.
Groups are groupOfName objects.
Rights are also groupOfNames.
Users are members of groups and groups are members of rights.
To exemplify my problem:
User: cn=example,ou=users,dc=mydomain
Group: cn=supervisors,ou=groups,dc=mydomain
Right: cn=someRight,ou=rights,dc=mydomain
For instance someRight should give all members of supervisors the right to modify other users.
At the moment the ACL is related to the group.
Access to dn.sub=”ou=users,dc=mydomain”
By group.exact=”cn=supervisor,ou=groups,dc=mydomain” write
By self read
To use the rights I’d need an ACL with a group of group.
Access to dn.sub=”ou=users,dc=mydomain”
By group.exact=”cn=someRight,ou=rights,dc=mydomain” write
Should allow all members of all groups that are member of someRight to modify users.
Is this possible or is groupOfNames the wrong class to represent group rights?
Hi,
This can be acheived using ACL sets. There is in fact an example of exactly this use case in the admin guide!
http://www.openldap.org/doc/admin24/access-control.html#Sets - Granting rights based on relationships
It is noted in the documentation that sets are experimental. Just to add a word onto that, I use sets in several production environments, and have absolutely no stability problems.
However, depending on the sets you use, the performance hit can be important (sets can fire off thousands of search requests just to evaluate one ACL, if they're badly written). Also, ACLs with sets are not cached.
Hope this helps, Jonathan
Hi,
This can be acheived using ACL sets. There is in fact an example of exactly this use case in the admin guide!
http://www.openldap.org/doc/admin24/access-control.html#Sets - Granting rights based on relationships
It is noted in the documentation that sets are experimental. Just to add a word onto that, I use sets in several production environments, and have absolutely no stability problems.
However, depending on the sets you use, the performance hit can be important (sets can fire off thousands of search requests just to evaluate one ACL, if they're badly written). Also, ACLs with sets are not cached.
Hope this helps, Jonathan
Thanks a lot! This should work. But unfortunately it does not :-(
My ACL looks like this now:
access to dn.sub="ou=agents,dc=myDomain" filter=(objectclass=person) by set="[cn=UserManagement,ou=rights,dc=myDomain]/member*" write by self read
cn=Test,ou=agents,dc=myDomain is a member of cn=supervisor,ou=groups,dc=myDomain which is a member of cn=UserManagement,ou=rights,dc=myDomain
Test has write access to all other agents. But he still has the right when I remove cn=supervisor... from the Usermanagement group.
Any idea why? How can I debug ACLs? Is it possible so print infos or do something like setting breakpoints?
Jan
On 16/11/2009 12:08, Jan Fricke wrote:
Hi,
This can be acheived using ACL sets. There is in fact an example of exactly this use case in the admin guide!
http://www.openldap.org/doc/admin24/access-control.html#Sets - Granting rights based on relationships
It is noted in the documentation that sets are experimental. Just to add a word onto that, I use sets in several production environments, and have absolutely no stability problems.
However, depending on the sets you use, the performance hit can be important (sets can fire off thousands of search requests just to evaluate one ACL, if they're badly written). Also, ACLs with sets are not cached.
Hope this helps, Jonathan
Thanks a lot! This should work. But unfortunately it does not :-(
My ACL looks like this now:
access to dn.sub="ou=agents,dc=myDomain" filter=(objectclass=person) by set="[cn=UserManagement,ou=rights,dc=myDomain]/member*" write by self read
cn=Test,ou=agents,dc=myDomain is a member of cn=supervisor,ou=groups,dc=myDomain which is a member of cn=UserManagement,ou=rights,dc=myDomain
Test has write access to all other agents. But he still has the right when I remove cn=supervisor... from the Usermanagement group.
Any idea why? How can I debug ACLs? Is it possible so print infos or do something like setting breakpoints?
Yes. Use loglevel acl (or 128) and you will see extensive information about ACL interpretation.
Of course, if your user still has right access when the ACL you pasted doesn't give it to him, it is probably because this access is granted by a previous ACL. Remember that ACLs are a list, and the first rule to match a target will win.
Regards, Jonathan
Yes. Use loglevel acl (or 128) and you will see extensive information about ACL interpretation.
Of course, if your user still has right access when the ACL you pasted doesn't give it to him, it is probably because this access is granted by a previous ACL. Remember that ACLs are a list, and the first rule to match a target will win.
Regards, Jonathan
Oh yeah SUCCESS!
Thanks a lot!
by set="user & ([cn=UserManagement,ou=roleRights,dc=myDomain]/member*)" write
did the job.
openldap-technical@openldap.org