Форум проекта Pro-LDAP.ru

Администрирование OpenLDAP => Вопросы безопасности => Access Control List (ACL) => Тема начата: vk от 13 Октябрь 2013, 12:32:58

Название: Управляемая публичность данных
Отправлено: vk от 13 Октябрь 2013, 12:32:58
Здравствуйте!
ЛДАП настроен так, что у простых пользователей нельзя прочитать многие атрибуты (например, sn)
Есть категория пользователей, которым данные реквизиты нужно открыть.

Вопрос состоит в следующем - как написать правило доступа "у определенных пользователей атрибут sn могут читать все"?

Что-то типа
access to group="cn=PublicPeople,dc=example,dc=com" attrs=sn
by * read

Т.е. у группы PublicPeople есть атрибут member, и у всех, кто упомянут в member, можно было прочитать sn
Название: Re: Управляемая публичность данных
Отправлено: egor от 14 Октябрь 2013, 04:29:41
Здравствуйте!
На "чистой" БД стандартными ACL выполнить такой финт не получится. Но если использовать наложение memberof (http://pro-ldap.ru/forum/index.php?topic=50.msg176#msg176), то можно уже кое-что придумать:
Код: [Выделить]
access to filter=(memberof=cn=PublicPeople,dc=example,dc=com) attrs=sn
    by * read
access to attrs=sn
    by * none
access to *
    by * read
Кажется, то, что Вы хотели.

Егор
Название: Re: Управляемая публичность данных
Отправлено: vk от 14 Октябрь 2013, 19:15:04
Да, похоже это именно то, что нужно!
Правда придется подключать дополнительное наложение...
Спасибо большое, попробую.

П.С. не подскажите еще, как настроить фильтр, если заранее dn группы неизвестен?
Например - есть подразделения
ou=a,dc=example,dc=com
ou=b,dc=example,dc=com
..
ou=z,dc=example,dc=com
в каждом из них есть "контактные лица", перечисленные в
cn=PublicPeople,ou=a,dc=example,dc=com
cn=PublicPeople,ou=b,dc=example,dc=com
..
cn=PublicPeople,ou=z,dc=example,dc=com

Как лучше указать правило в таком случае?
Название: Re: Управляемая публичность данных
Отправлено: egor от 15 Октябрь 2013, 02:04:00
Здравствуйте! Гибкость ACL в OpenLDAP имеет свои пределы =) . Отобрать записи в условии <what> директивы access to можно либо по поддереву (dn), либо по фильтру (filter). Как Вы понимаете, по поддереву в данном случае отбирать бессмыслено, поэтому и пришлось вводить наложение memberof и применять такой фильтр. Проблема в том, что у атрибута memberOf нет правила соответствия SUBSTR, то есть построить фильтр типа (memberOf=cn=PublicPeople,*) не получится, а следовательно одним красивым ACL Вашу задачу не решить.

Но это не значит, что задача не решается в принципе =) . Можно попытаться решить её "в лоб" фильтром типа (|(memberOf=cn=PublicPeople,ou=a,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=b,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=z,dc=example,dc=com)) , надеюсь, подразделений у Вас меньше, чем 16 =) , либо разделить такой ACL на несколько однотипных.

Егор
Название: Re: Управляемая публичность данных
Отправлено: vk от 15 Октябрь 2013, 02:15:58
Здравствуйте, Егор!
Цитата: egor от 15 Октябрь 2013, 02:04:00
Можно попытаться решить её "в лоб" фильтром типа (|(memberOf=cn=PublicPeople,ou=a,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=b,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=z,dc=example,dc=com)) , надеюсь, подразделений у Вас меньше, чем 16 =)
Подразделений у нас около пятидесяти =(

П.С. Регэксп тоже не получится?
П.П.С. Да, еще. Каждый пользователей имеет атрибут ou. Пробовал сделать конкатенацией строк что-то типа
to filter=(memberof="([cn=PublicPeople,ou=]+this/ou+[,dc=example,dc=com])") attrs=sn * read
Для наборов работает, а здесь нет.
Название: Re: Управляемая публичность данных
Отправлено: egor от 15 Октябрь 2013, 03:12:18
Здравствуйте!
Цитата: vk от 15 Октябрь 2013, 02:15:58
П.С. Регэксп тоже не получится?
Регулярные выражения применяются к DN, к атрибутам применяется правило соответствия SUBSTR, о чём я писал выше.

Цитата: vk от 15 Октябрь 2013, 02:15:58
П.П.С. Да, еще. Каждый пользователей имеет атрибут ou. Пробовал сделать конкатенацией строк что-то типа
to filter=(memberof="([cn=PublicPeople,ou=]+this/ou+[,dc=example,dc=com])") attrs=sn * read
Для наборов работает, а здесь нет.
Наборы (set), также как и группы (group), используются ТОЛЬКО в условии by <who> директивы access to.

Цитата: vk от 15 Октябрь 2013, 02:15:58
Подразделений у нас около пятидесяти =(
Если не хотите перечислять 4 (50/16) ACL с такими ужасными фильтрами, есть 2 обходных пути:
Всё зависит от Вашей политики ведения каталога.

Егор
Название: Re: Управляемая публичность данных
Отправлено: vk от 24 Октябрь 2013, 18:30:10
Здравствуйте!
Блин, ничего путнего я так и не придумал. Ни один вариант не нравится.
Но что поделать, видимо придется делать костыль из перечисления всех подразделений.

Подскажите, сильно ли влияет количество ACL на быстродействие системы?
Просто у меня уже 16 строчек ACL, если к ним прибавится еще 4-6 - не сильно ли громоздко получится?
Название: Re: Управляемая публичность данных
Отправлено: egor от 25 Октябрь 2013, 09:27:56
Здравствуйте!
Цитата: vk от 24 Октябрь 2013, 18:30:10
Подскажите, сильно ли влияет количество ACL на быстродействие системы?
Просто у меня уже 16 строчек ACL, если к ним прибавится еще 4-6 - не сильно ли громоздко получится?
Само собой, обработка ACL занимает определённое время, но, мне кажется, принципиальной разницы между 16-ю и 20-ю ACL нет. К тому же обработка прекращается на первом сработавшем ACL, так что продумайте и расположите их грамотно, чтобы избежать лишних проверок.

Егор