Пользователи LDAP и веб-приложение
Мы создали веб-приложение (работающее в нашей интрасети), которое полагается на наш каталог LDAP (активный каталог) для своих пользователей. Вместо того, чтобы «синхронизировать» пользователей каталога, скажем, с таблицей «пользователь» в нашей базе данных приложения (MySQL), мы используем каталог LDAP так же, как мы используем базы данных.
При создании отношения между объектом, извлеченным из MySQL, и пользователем LDAP мы используем GUID пользователя (который является уникальной строкой).
В нашем каталоге никогда не будет более 300 пользователей (никогда). Мы установили выделенный DC (контроллер домена) для обслуживания нашего запроса приложения. Сетевая задержка не проблема.
В нашем коде мы могли бы заменить несколько строк кода, чтобы перейти от использования LDAP к использованию MySQL и «пользовательской» таблицы (средства отображения данных великолепны)
Вы бы сделали это (без синхронизации таблицы пользователя)? Каковы ваши аргументы против этого (способ сделать это)?
редактировать
Мы используем таблицу ‘user’, но она очень просто поэтому объединение SQL не является проблемой, мы знаем, что это будет иметь лучшую производительность с полный пользовательская таблица, но ищем другие аргументы против использования LDAP
CREATE TABLE `user` (
`_id` int(4) unsigned NOT NULL AUTO_INCREMENT,
`guid` varchar(255) NOT NULL,
PRIMARY KEY (`_id`)
);
Решение
Я бы не делал это. Я бы синхронизировал данные пользователей, за исключением пароля при каждом входе в систему. Таким образом, у вас есть текущие данные вашего приложения в его базе данных, и вы можете использовать функции объединения ваших баз данных, чтобы получить всю необходимую информацию, не обращаясь к различным системам. Я бы использовал LDAP только для аутентификации и, возможно, модель авторизации на основе LDAP-Group.
- Таким образом, вам не нужно беспокоиться с паролями и паролями
политики. - А после входа в систему вы полностью независимы от LDAP-сервера.
- Отсутствующий сервер LDAP не повлияет на уже вошедших в систему пользователей, только новые
логины не будут работать.
И хотя objectGUID уникален, он уникален во всем вашем LDAP и не обязательно в вашем приложении.
У нас часто возникает проблема, заключающаяся в том, что в LDAP пользователь, которого мы недавно создали, а не переименовывается при изменении имени пользователя (из-за брака или развода). Но вы можете не захотеть создавать нового пользователя в этом случае в вашем приложении. С вашей собственной таблицей пользователей вы можете просто изменить ObjectGUID для пользователя, и внутренний идентификатор приложения пользователя останется прежним, но будет ссылаться на совершенно нового пользователя в LDAP.
Другие решения
Я бы определенно сделал это для аутентификации, базового профиля пользователя и статуса пользователя. Запись AD для пользователя, скорее всего, более актуальна, чем данные, которые вы имеете для пользователя. Это избавляет вас от необходимости управлять паролями для пользователей. Вам не нужно хранить их или предоставлять средства для их изменения. Когда статус пользователя отключен в Active Directory, ваш пользователь больше не сможет использовать ваши приложения. Если имя пользователя, адрес электронной почты, номер телефона изменяются в AD, то у вас всегда будут самые свежие данные, и вам не нужно будет предоставлять средства для управления ими.
objectGUID это идеальный способ связать свой аккаунт, так как он уникален и неизменен.