Реализация безопасности на основе ролей в LDAP - PullRequest
7 голосов
/ 05 ноября 2011

Я работаю над реализацией безопасности на основе ролей в LDAP и Java. В частности, у меня есть следующие объекты, которые мне нужно представить в LDAP:

  • Пользователи
  • Корпоративные группы пользователей - HR, финансы и т. Д.
  • Разрешения - DOCUMENT_READ, DOCUMENT_MODIFY и т. Д.
  • Роли - АДМИН, ГОСТИ и т. Д.

Роли - это, в основном, группы разрешений, и они могут быть назначены пользователю или группе пользователей.

Я думал представить их в LDAP следующим образом:

  • Пользователи - классы Person и uidObject с атрибутом userPassword.
  • Группы пользователей - класс организационного подразделения, под которым пользователи находятся расположен.
  • Роли - класс объекта groupOfNames.
  • Разрешения - не уверен насчет этого, возможно, также groupOfNames класс.

Идея состоит в том, чтобы получить быстрый доступ от пользователя или группы к списку ролей, которые имеет этот пользователь или группа. Я знаю, что могу помещать пользователей и группы в атрибуты роли «член», но тогда мне придется сканировать все роли, чтобы найти те, в которых этот пользователь указан в списке. Есть ли способ иметь что-то вроде атрибута "member" в объекте Person?

В общем, кто-нибудь знает о хорошей реализации безопасности на основе ролей в LDAP? Я не мог найти хорошую документацию или учебники по этому вопросу. В настоящее время я использую ApacheDS в качестве сервера LDAP, но я открыт для предложений.

Ответы [ 3 ]

8 голосов
/ 06 ноября 2011

Пользователи: inetOrgPerson

Коллекции: organizUnit, но остерегайтесь попыток тиражировать вашу организационную структуру в вашем каталоге LDAP: это обычно ошибка, так как организации меняются, а пользователи перемещаются по организации. Вам следует рассмотреть возможность использования атрибута ou .

Роли: организационная роль. Я использовал группы ролей как groupOfUniqueNames, но это было ошибкой, я должен был продолжать использовать organizRole, чтобы роли были просто рекурсивными.

Разрешение: на самом деле это просто роль или атрибут роли. Если вы используете CMA, они определены в web.xml, а не в LDAP.

Как я уже сказал, не пытайтесь заставить свое дерево LDAP отражать вашу организацию. Сделайте это своей собственной организацией. Я использую многозначные атрибуты везде, где это необходимо. Я использую организационный блок в основном для слоев внутри самого LDAP или там, где я нарушил свои правила выше; -)

OpenLDAP имеет оверлей ссылочной целостности, который может многое сделать для вас.

Есть несколько очень полезных советов по структуре LDAP в Освоение OpenLDAP Мэттом Батчером и более высокий уровень просмотра всего этого в Понимание и развертывание служб каталогов LDAP Хоус и др.

2 голосов
/ 28 июля 2015

Еще одна опция: проверить управление доступом на основе атрибутов ().ABAC - это эволюция RBAC.Он использует атрибуты (которые представляют собой ярлыки для пользователя, ресурса, контекста) и политики для определения того, что разрешено, а что нет.

Пример: пользователь с ролью == manager в отделе == продажи могут выполнить действие == изменить документ типа == заказ на покупку, если сумма заказа на поставку <= предел одобрения пользователя. </p>

Подробнее об ABAC можно прочитать на веб-сайте NIST .

0 голосов
/ 26 февраля 2014

Проверьте Крепость.Он соответствует ANSI RBAC INCITS 359 и построен на LDAP.Исходный код с открытым исходным кодом, и вы можете скачать готовые двоичные файлы, включающие OpenLDAP, отсюда: http://iamfortress.org/

...