Использование учетных данных ldap и поиск в таблицах postgresql
Я новичок в LDAP и хочу использовать его в будущем проекте с База данных PostgreSQL.
Предположим, что я выполню аутентификацию с сервером LDAP, поэтому таблица пользователей не будет вставлена в базу данных PostgreSQL, в базе данных PostgreSQL у меня будут другие таблицы, которые должны быть связаны с идентификатором пользователя (которые будут извлечены из LDAP), поэтому мне нужно добавить столбец в каждую из этих таблиц с именем uid, в котором хранится значение uid пользователя. Верна ли моя идея?
да. Имеет смысл. Пока ссылочный ключ (например, uid) уникален и не будет изменен после его создания. Идея состоит в том, чтобы найти свойство в записи пользователя ldap, которое не будет изменено ...
@Gabriel: да, это соответствует моим требованиям, как я уже сказал, я новичок в LDAP, поэтому я ищу лучший способ связать его с другой базой данных. :)
Какой сервер LDAP вы используете? (Открыть LDAP, Active Directory и т. д.?)
@GabrielLuci: На данный момент я не знал, что вы порекомендуете? ^^
Ничего не рекомендую. Мы используем Active Directory на работе, так что это все, что я когда-либо использовал. Я спрашиваю только потому, что разные серверы будут работать по-разному (например, Active Directory не использует атрибут uid)
@GabrielLuci, а для данных, хранящихся в другой базе данных, для которых требуется идентификатор пользователя, как вы можете управлять этим с помощью Active Directory? (Благодарю за ваш ответ)
Я добавил ответ с некоторыми рекомендациями.
Ответы 1
То, что вы описываете, прекрасно. Просто имейте в виду, что какой атрибут вы используете в качестве уникального идентификатора, зависит от того, какой каталог LDAP вы используете.
Я действительно знаю только Active Directory, которая вообще не использует атрибут uid. У AD есть несколько обязательных уникальных атрибутов:
distinguishedName: описывает, где находится объект в каталоге. Выглядит это примерно так:CN=Gabriel Luci,OU=Users,DC=domain,DC=com. Это общее для LDAP в целом, но может называться иначе в других каталогах LDAP.sAMAccountName: это обычно называется «имя пользователя». Он должен быть уникальным в домене, но его можно изменить.userPrincipalName: использует формат[email protected]. Он должен быть уникальным в лесу AD, но его можно изменить («лес» - это когда в одной организации есть несколько доменов AD).objectSid: (обычно просто называется SID). Он хранится в виде массива байтов, но может быть преобразован в строку, которая выглядит какS-1-5-32-##########-###########-##########-#####. Это то, что используется Windows в разрешениях безопасности для предоставления учетным записям прав доступа к файлам и т. д. Это не может быть изменено.objectGuid: GUID, который автоматически назначается при создании учетной записи. Это не может быть изменено.
Первые три удобочитаемы (обычно они содержат имя человека). Два других нет, но они также остаются неизменными на протяжении всего срока службы объекта (если человек изменит свое имя, SID и GUID останутся прежними).
Какой из них вы используете, зависит от ваших требований. distinguishedName уникален и позволяет вам напрямую связываться с объектом, когда вам нужно (в отличие от необходимости искать sAMAccountName, чтобы найти учетную запись). Но если вы хотите чего-то, что никогда не изменится, даже если имя человека изменится, тогда лучше всего подойдет objectSid или objectGUID.
очень интересное объяснение ^ _ ^ большое спасибо.
Правильно, если соответствует вашим требованиям :) Ответить можете только вы.