Hello
Many badly designed software fetch all attribute when looking up an user in the directory, instead of just fetching the one they are interested in.
My user objects have jpegPhoto attribute, which get fetched with the whole user object. jpegPhoto are big, so this cause unnescesary load on the network and LDAP servers and it slows down login process on the bad software.
Setting up ACL to deny read access to jpegPhoto is not always feasible, nor it is easily maintainable.
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
AFAIK, there is no way to do that for now. Am I right?
I suspect an overlay would be the right way of implementing it (slapo-cloak?). Would it be of enough interest to go into server/slapd/overlays ? If it does, I will contribute it.
Emmanuel Dreyfus wrote:
Many badly designed software fetch all attribute when looking up an user in the directory, instead of just fetching the one they are interested in.
My user objects have jpegPhoto attribute, which get fetched with the whole user object. jpegPhoto are big, so this cause unnescesary load on the network and LDAP servers and it slows down login process on the bad software.
Setting up ACL to deny read access to jpegPhoto is not always feasible, nor it is easily maintainable.
Why not a simple ACL for a group? Do the applications bind anonymously?
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote:
Why not a simple ACL for a group? Do the applications bind anonymously?
Of course it does. I said it was ill-designed :-)
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.
Fortunately, the only apps I have that use the jpegPhoto are wise enough to provide a set of attributes.
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
Why not a simple ACL for a group? Do the applications bind anonymously?
Of course it does. I said it was ill-designed :-)
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.
Fortunately, the only apps I have that use the jpegPhoto are wise enough to provide a set of attributes.
I think what you propose makes sense, I see few cases where it would be definitely useful. In general, anything gives an administrator the possibility to tune resource exhaustion sounds welcome. I think an overlay is the right place.
With respect to your specific problem, you should be able to do something close to what you need by loading your jpegPhoto as jpegPhoto;x-mustberequested, then only allow access to this attribute and not to plain jpegPhoto.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
With respect to your specific problem, you should be able to do something close to what you need by loading your jpegPhoto as jpegPhoto;x-mustberequested, then only allow access to this attribute and not to plain jpegPhoto.
Please disregard: never answer emails while having a snack :)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
Why not a simple ACL for a group? Do the applications bind anonymously?
Of course it does. I said it was ill-designed :-)
So why not point these ill-designed apps to a different DSA implemented by back-ldap with such an ACL?
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.
Fortunately, the only apps I have that use the jpegPhoto are wise enough to provide a set of attributes.
AFAIK commonly used LDAP browsers never explicitly request jpegPhoto when displaying a *single* entry. My web2ldap explicitly limits the attrs to be returned when searching mutiple entries for not exhausting network bandwidth. But explicitly requesting binary attrs when displaying a single entry does not make sense for a generic LDAP client application.
Off course if you're not using such application at all you won't have a problem.
I think it would be interesting if an ACL could distinguish whether the search request has scope base and grant read access to jpegPhoto only in this case.
Ciao, Michael.
Michael Ströder wrote:
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
Why not a simple ACL for a group? Do the applications bind anonymously?
Of course it does. I said it was ill-designed :-)
So why not point these ill-designed apps to a different DSA implemented by back-ldap with such an ACL?
A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it.
I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.
Fortunately, the only apps I have that use the jpegPhoto are wise enough to provide a set of attributes.
AFAIK commonly used LDAP browsers never explicitly request jpegPhoto when displaying a *single* entry. My web2ldap explicitly limits the attrs to be returned when searching mutiple entries for not exhausting network bandwidth. But explicitly requesting binary attrs when displaying a single entry does not make sense for a generic LDAP client application.
Off course if you're not using such application at all you won't have a problem.
I think it would be interesting if an ACL could distinguish whether the search request has scope base and grant read access to jpegPhoto only in this case.
Technically, it would be relatively easy to implement. Theoretically, I see it relatively critical, because it would imply that a specific access (read) depends on what operation and operation parameters are used. Looks a little bit disguising. Note that it doesn't seem to be in conflict with any specification. As in many cases, no objection to implementing it, although I would use it with care.
The suggested "feature", on the contrary, seems to be a little bit more linear: the administrator decides that some attributes (e.g. bandwidth intensive ones) are not shown by default, unless explicitly requested. I see a parallel with soft and hard search limits: the soft limit applies, unless a specifically requested limit is present. In that case, the requested limit applies, provided it complies with the hard limit.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati ando@sys-net.it wrote:
The suggested "feature", on the contrary, seems to be a little bit more linear: the administrator decides that some attributes (e.g. bandwidth intensive ones) are not shown by default, unless explicitly requested. I see a parallel with soft and hard search limits: the soft limit applies, unless a specifically requested limit is present. In that case, the requested limit applies, provided it complies with the hard limit.
I wonder what is the best way of implementing such an overlay:
1) search with attrsonly=1 before the real search if attribute list is NULL and attrsonly=0 { perform searches with attrsonly=1 gather le list of returned attributes filter out the cloaked ones modify the original search operation to use that attribute set } perform the search
2) set a callback on search operations if attribute list is NULL and attrsonly=0 { set a callback on search } perform the search if called back { filter out cloaked attributes }
Approach one duplicate the search, and it can waste some time, but it avoid fetching the cloaked attribute. If it is dynamically generated, there can be some benefit.
Pierangelo Masarati ando@sys-net.it wrote:
The suggested "feature", on the contrary, seems to be a little bit more linear: the administrator decides that some attributes (e.g. bandwidth intensive ones) are not shown by default, unless explicitly requested. I see a parallel with soft and hard search limits: the soft limit applies, unless a specifically requested limit is present. In that case, the requested limit applies, provided it complies with the hard limit.
Here is slapo-cloak, an overlay to hide selected attribute twhen they are not explicitely requested. http://www.openldap.org/its/index.cgi/Incoming?id=5872;page=5
Deeback are welcome.
Michael Ströder michael@stroeder.com wrote:
So why not point these ill-designed apps to a different DSA implemented by back-ldap with such an ACL?
Yes, that would work. It moves the setup to clients, with might be a bit more complicated to handle than the server for system administrators: there can be many clients, some of them you don't manage yourself.
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
So why not point these ill-designed apps to a different DSA implemented by back-ldap with such an ACL?
Yes, that would work. It moves the setup to clients, with might be a bit more complicated to handle than the server for system administrators: there can be many clients, some of them you don't manage yourself.
=> Use back-ldap based setup for all anon access. Access to the real DSA only to authenticated clients.
Ciao, Michael.
-
manu＠netbsd.org -
Michael Ströder -
Pierangelo Masarati