Hi everybody,
I hope I am sending this email to the correct mailing list, if not please excuse me.
I am trying to find a way to hide/unhide attributes on my DIT (openldap-2.4.21) and I cannot find a way to do this. What I mean by hide/unhide is that I want specific attributes to be listed with ldapsearch only if the owner of the records agrees. I did not find any feature that does this "automatically", so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
Is there a way to support such a behavior (maybe through an additional overlay, or oclAccess, etc)?
If someone knows an answer I would be delighted to know so.
Thank you all for your time in advance,
mamalos
PS. I have submitted a similar question to an "ldap programmers" forum, because I thought that openldap lists don't support such questions. Nevertheless, I found analogous questions being asked on this list by googling, so I thought I should give it a try.
Am 16.03.2011 16:31, schrieb George Mamalakis:
so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
You mean something like this?
access to attrs=mail by group="cn=publish mail,ou=Groups,dc=example,dc=com" read by * none
See slapd.access(5) for details.
Regards, Christian Manal
On 16/03/2011 17:49, Christian Manal wrote:
Am 16.03.2011 16:31, schrieb George Mamalakis:
so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
You mean something like this?
access to attrs=mail by group="cn=publish mail,ou=Groups,dc=example,dc=com" read by * noneSee slapd.access(5) for details.
Regards, Christian Manal
Christian thank you for your reply,
No, this is not what i mean. In your example you allow the mail attribute to be shown to those belonging to the cn=publish mail,ou=Groups,dc=example,dc=com group. I want *all* (not those belonging to that group) authenticated users to see this attribute if the owner of the record is member of this group.
I think I am reaching a partial solution which I will send once I test it.
Thanx again for your reply.
On Wed, Mar 16, 2011 at 05:31:27PM +0200, George Mamalakis wrote:
I am trying to find a way to hide/unhide attributes on my DIT (openldap-2.4.21) and I cannot find a way to do this. What I mean by hide/unhide is that I want specific attributes to be listed with ldapsearch only if the owner of the records agrees. I did not find any feature that does this "automatically", so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
There are several ways to do that. See my paper on ACL design for some examples:
http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
Parts of section 10.5 might be useful, but as that is a rather complex example I suggest you do not start there!
Andrew
On 16/03/2011 18:21, Andrew Findlay wrote:
On Wed, Mar 16, 2011 at 05:31:27PM +0200, George Mamalakis wrote:
I am trying to find a way to hide/unhide attributes on my DIT (openldap-2.4.21) and I cannot find a way to do this. What I mean by hide/unhide is that I want specific attributes to be listed with ldapsearch only if the owner of the records agrees. I did not find any feature that does this "automatically", so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
There are several ways to do that. See my paper on ACL design for some examples:
http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
Parts of section 10.5 might be useful, but as that is a rather complex example I suggest you do not start there!
Andrew
Andrew,
I haven't read your paper yet, but I will, since it seems very informing! I came up to a "partial solution" in the meantime that reads like this:
access to dn.subtree="ou=People,dc=example,dc=com" attrs=mail by anonymous none by self write by set="this & [cn=Publish Mail,ou=Groups,dc=example,dc=com]/uniqueMember " read by * none
with this acl I manage to filter out anonymous users, allow self to change/add their mail and show everybody else the entry's mail, if the dn belongs to the specific group. Since anonymous is out, the rest of the users must be authenticated, and hence I 'converge' to my wished 'by users read'. It is not mathematically *exactly* what I wished for (I think...since I am not sure what other sort of users would exist, but the truth is that other dn's would be able -somehow- to access this tree...), but it is very, very, very close to it.
Now to your paper, do you propose a solution/example that does exactly what I wish? If so, is it located in section 10.5 explicitly or implicitly?
Thanx again for your immediate answer and help,
mamalos
On Wed, Mar 16, 2011 at 07:37:23PM +0200, George Mamalakis wrote:
access to dn.subtree="ou=People,dc=example,dc=com" attrs=mail by anonymous none by self write by set="this & [cn=Publish Mail,ou=Groups,dc=example,dc=com]/uniqueMember " read by * none
Now to your paper, do you propose a solution/example that does exactly what I wish? If so, is it located in section 10.5 explicitly or implicitly?
Not exactly what you want, but the example in 10.5 might provide a useful framework. It works by defining sets of attributes, then selectively granting access to entries based on the setting of a visibility attribute in the entry, then selectively granting access to attribute sets based on who is asking.
You want to allow individual entries to select the visibility of mail attributes. The group and set scheme that you propose is one way to do that (though I would use member rather than uniqueMember). Another might be to use a visibility attribute in the entry and a series of rules of the form:
access to filter="(&(objectclass=person)(visibility=mail-users))" attrs="mail" by users read by * break
That rule would be one of a series, ending up with a default-deny, perhaps something like this:
access to filter="(objectclass=person)" by * none
You would need to handle 'self' access in an earlier rule.
Andrew
On 17/3/2011 12:14 μμ, Andrew Findlay wrote:
On Wed, Mar 16, 2011 at 07:37:23PM +0200, George Mamalakis wrote:
access to dn.subtree="ou=People,dc=example,dc=com" attrs=mail by anonymous none by self write by set="this& [cn=Publish Mail,ou=Groups,dc=example,dc=com]/uniqueMember " read by * none Now to your paper, do you propose a solution/example that does exactly what I wish? If so, is it located in section 10.5 explicitly or implicitly?
Not exactly what you want, but the example in 10.5 might provide a useful framework. It works by defining sets of attributes, then selectively granting access to entries based on the setting of a visibility attribute in the entry, then selectively granting access to attribute sets based on who is asking.
You want to allow individual entries to select the visibility of mail attributes. The group and set scheme that you propose is one way to do that (though I would use member rather than uniqueMember). Another might be to use a visibility attribute in the entry and a series of rules of the form:
access to filter="(&(objectclass=person)(visibility=mail-users))" attrs="mail" by users read by * break
That rule would be one of a series, ending up with a default-deny, perhaps something like this:
access to filter="(objectclass=person)" by * none
You would need to handle 'self' access in an earlier rule.
Andrew
Andrew,
thank you very much for your help. I find your approach very interesting and I will definitely look into it. It seems much more controllable/versatile than my way.
openldap-technical@openldap.org
-
Andrew Findlay -
Christian Manal -
George Mamalakis