Особенности проектирования каталогов LDAP - PullRequest
0 голосов
/ 25 февраля 2012

В организации каждый сотрудник использует несколько сервисов, и поэтому я решил использовать сервер OpenLDAP для хранения информации, связанной с пользователем, в одном централизованном месте (что в настоящее время не так, что вызывает много головной боли). Прочитав пару книг и бесчисленные тексты в Интернете, я все еще не могу определиться с выбором между двумя подходами к дизайну.

1. Поместить минимальные персональные данные людей (имена, телефоны, электронную почту) в ou = people, dc = example, dc = com и записи для конкретного приложения в отдельные поддеревья, связывая их с пользователями через DN-s. Как, например, отдельное поддерево для электронной почты с псевдонимами, квотами и т. Д .; отдельное поддерево для учетных данных УАТС и т. д. Таким образом, доступ к приложению более прост. С другой стороны, та же информация повторяется в разных поддеревьях: электронная почта пользователя и uid в разделе «ou = people, dc = example, dc = com» и запись почтового ящика, связывающая адрес электронной почты с почтовым ящиком пользователя ( что совпадает с UID пользователя).

2. Другой подход, также замеченный в некоторых уроках, состоит в том, чтобы вставлять личные данные приложения в объект человека, используя вспомогательные классы, как здесь:

http://www.watersprings.org/pub/id/draft-srivastava-ldap-mail-00.txt

с фактической схемой здесь:

http://www.netfrag.org/webnews/article.php?id=89&group=nfo.links.computing

Мне кажется, что первый подход более разумен, но, поскольку это моя первая серьезная реализация каталога LDAP с участием большого количества пользователей, я бы предпочел обратиться за советом к более опытным специалистам по LDAP.

Мои извинения за, возможно, слишком общий вопрос.

1 Ответ

1 голос
/ 28 февраля 2012

Ничего из вышеперечисленного.

Первая идея - просто ужасный дизайн.Вы бы поместили все свои столбцы с плавающей запятой в одну таблицу в базе данных?

Вторая идея использует интернет-черновик, срок действия которого истек почти 13 лет назад.Есть причина, по которой он никогда не стал RFC.

Используйте класс объектов inetOrgPerson и вставьте туда все.Используйте каталог, чтобы выразить структуру каталога, например, Пользователи, Группы, Роли, ... не чтобы изолировать типы данных в соответствии с вашей первой идеей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...