Хранение профилей пользователей

Я хочу сохранить информацию профиля пользователя. Немного поработав в Интернете, я запутался в следующих вариантах:

  1. Используйте сервер LDAP (пример: Open DJ) - я могу писать клиентов Java, которые могут взаимодействовать с сервером LDAP с помощью API LDAP.

  2. Сохраните профиль пользователя в базе данных в виде документа JSON (например, в Elastic DB) - базы данных No SQL могут затем индексировать документы, чтобы сократить время поиска.

Какие факторы следует иметь в виду, прежде чем выбрать один из подходов?


identity ldap openldap opendj
person sunsin1985    schedule 08.01.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Для начала, если вы храните пароли, то использование LDAP - это простая задача IMO. См. http://smart421.com/smart-identity-and-fraud/why-bother-with-an-ldap-anyway/.

В противном случае я бы рекомендовал вам сделать PoC для каждого решения (не забудьте добавить индексы для OpenDJ, и вы также можете использовать Rest2LDAP), посмотрите, как они удовлетворяют ваши потребности. Оба продукта имеют открытый исходный код, поэтому начать работу легко.

person JnRouvignac    schedule 09.01.2016
comment
Хороший ответ. Когда вы думаете об этом, LDAP - хороший выбор без использования sql и обычно имеет встроенные средства управления доступом. - person jwilleke; 09.01.2016

arrow_upward
1
arrow_downward

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

Если вы начинаете с нуля и у вас в основном внешние, неизвестные пользователи, которые не взаимодействуют с вашей инфраструктурой иначе, как это одно приложение, то LDAP не лучший выбор из-за накладных расходов, которые вы получаете при создании и управлении сервером. Тогда кажется, что лучше подходит облегченный подход JSON (даже если L в LDAP означает «облегченный»).

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

См. Также этот вопрос для получения дополнительных сведений. Причины для хранения пользователей 'данные в LDAP вместо СУБД

person cdonner    schedule 08.01.2016
comment
Спасибо за ответ. Насколько я понимаю, LDAP хранит данные в древовидной структуре, тогда как база данных без SQL, такая как эластичный поиск, будет хранить документы JSON в плоской структуре. Существуют ли какие-либо конкретные варианты использования, в которых я могу столкнуться с проблемами, если я не использую древовидную структуру LDAP, если я использую базу данных без SQL? Мне приходит в голову один вариант использования, когда всех пользователей определенной группы нужно переместить в другую группу. Не могли бы вы поделиться своими мыслями по этому поводу? - person sunsin1985; 08.01.2016
comment
Большинство серверов LDAP используют плоскую иерархию для хранения только идентификаторов пользователей. Если он не используется также для файла и печати. (например, Microsoft Active Directory). LDAP - хороший выбор для no-sql и обычно имеет встроенные средства управления доступом, политики паролей и т. Д. И т. Д. - person jwilleke; 09.01.2016
comment
Я не понимаю, почему древовидная структура в LDAP важна для вас. Если вы не хотите организовать свою популяцию пользователей в виде иерархического дерева, например с организационными единицами (OU), то я не думаю, что тот факт, что данные LDAP хранятся в виде дерева, имеет для вас значение, потому что все пользовательские объекты в любом случае будут находиться в одном узле. - person cdonner; 10.01.2016