У нас есть набор различных веб-приложений, предназначенных для наших дистрибьюторов и партнеров. Некоторые из них представляют собой стандартные пакеты, такие как Alfresco, другие - это веб-сайты, созданные на заказ.
Все защищены логином. Мы бы хотели, чтобы у наших пользователей был единый логин для всех этих приложений. Поэтому мы рассматриваем возможность настройки сервера OpenLDAP для обслуживания всех запросов аутентификации этих приложений.
Где мы должны хранить права пользователей для конкретных приложений? Например, кто может использовать app1, кто может использовать app2 и с какой ролью? Должен ли он храниться в LDAP или в БД приложения?
Другими словами, должны ли мы сохранить LDAP просто для поиска базовой идентификации / аутентификации и отслеживать, кто может использовать какое приложение в БД каждого приложения? Или мы можем хранить всю эту информацию в LDAP (это имеет смысл)?
TIA для того, чтобы пролить свет.
Используйте LDAP для аутентификации пользователя и базу данных приложения, чтобы определить, есть ли у этого пользователя права. Вы мог сделайте это только в LDAP, но разделение имеет преимущества и фактически упрощает управление. Это не отличается от управления учетными записями пользователей в одной области и разрешениями файлов / папок в другой.
Для более детализированных разрешений, таких как «имеет права редактирования на главной странице», я бы оставил это на уровне приложения, но для простых разрешений уровня «имеет доступ для чтения / записи» я бы для простоты реализовал это в ldap.
Одна проблема, о которой следует знать, - это максимальное количество групп, с которыми пользователь может быть связан на некоторых платформах, поэтому я бы использовал настраиваемое имя для атрибута членства в группах приложений, чтобы вам даже не нужно было это учитывать.
Поместите все в LDAP, вот для чего.
Следует отметить, что, хотя может возникнуть соблазн использовать Active Directory из-за его возможностей LDAP, это может быть не лучшим выбором. AD, как и многие продукты Microsoft, обычно отлично работает, когда вы придерживаетесь продуктов Microsoft, и когда вам нужно начать смешивать среды, все становится необычным. Однако, к чести Microsoft, они значительно улучшились в этой области за последние несколько лет. Самая большая проблема, с которой вы можете столкнуться, - это если вам нужно внести какие-либо изменения в схему AD для поддержки ваших приложений. Изменения схемы не обязательно поддерживаются Microsoft и могут усложнить любые будущие обновления AD. Хотя, честно говоря, это верно для любого сервера LDAP, однако я бы сказал, что чаще всего изменения схемы вносятся на серверах LDAP. Если у вас есть существующий сервер AD, вы можете реализовать операцию синхронизации между вашим сервером LDAP (например, Red Hat Directory Server) и вашим сервером AD. Это может позволить вам синхронизировать имена пользователей, но сохранить системную информацию в каждом домене сервера. Да, это добавляет сложности администрированию, но в целом это один из самых гибких подходов.
В конце концов, централизованная аутентификация регулируется следующим образом:
"Where do you want your pain?"