Как настроить систему аутентификации с одним хранилищем учетных данных и несколькими методами / интерфейсами аутентификации?
Предыстория: у меня есть коллекция серверов на базе Linux (скажем, несколько десятков), которые размещены в разных местах. Некоторые серверы являются одиночными спутниками, в то время как другие размещаются вместе в одних и тех же дата-центрах. Некоторые из них являются физическими аппаратными серверами, а другие - виртуальными частными серверами. Серверы предоставляют такие сервисы, как электронная почта, хостинг веб-приложений, базы данных и серверные части некоторых пользовательских приложений. Сами серверы уже имеют инструменты для управления оборудованием, а также управление на уровне операционной системы (учетные записи администратора, управление виртуальным сервером и т. Д.).
Проблема: До сих пор для аутентификации различных сервисов на уровне приложений использовался ряд решений. Иногда это означало, что пароли учетных записей должны были храниться в нескольких местах. Лучшим решением было бы иметь единую систему аутентификации источника с централизованным управлением, которая позволяла бы каждой службе аутентифицировать пользователя из одного экземпляра его учетной записи и позволяла бы работать с одним элементом данных вместо того, чтобы выяснять, какие местоположения должны быть обновляется при создании, изменении и удалении учетной записи. Данные удостоверения могут быть реплицированы для обеспечения избыточности. (Обратите внимание, что цель здесь отличается от единого входа: вам нужно проходить аутентификацию отдельно для каждого приложения, но ваши учетные данные хранятся в одном месте. См. Этот вопрос.)
Несколько предыдущих вопросов предлагают LDAP, а также говорят о Kerberos. Этот вопрос задает вопрос о безопасности LDAP и требует сравнения между LDAP и Kerberos. Kerberos хорош, но в этом случае возможность единого входа не требуется, поэтому настройка Kerberos может оказаться излишней и привести к ненужной административной нагрузке. Этот вопрос расширяет сферу охвата сетевых устройств, и основное внимание уделяется уровню ОС, а не уровню приложений. В моем случае это просто проверка подлинности на уровне приложения. Это также означает, что существует большее разнообразие типов протоколов аутентификации, которые должны поддерживаться; PAM недостаточно. Этот вопрос требует альтернатив LDAP, но ответы указывают на LDAP, в любом случае, по веским причинам. NIS - это другое предлагаемое решение, но оно действительно не подходит в этом случае, потому что оно просто решает распространение информации о пароле (и другой), а не методы хранения, управления и аутентификации. Наконец, этот вопрос кажется довольно схожим, но основное внимание уделяется аутентификации VPN. (Здесь также есть похожий вопрос, но он не был достаточно точным, чтобы соответствовать ServerFault.)
LDAP является одним из источников аутентификации, которые я сейчас использую. Однако не все приложения могут использовать LDAP. Некоторым нужен интерфейс на основе HTTP, другие лучше всего работают с интерфейсом SQL. Например, необходимо запустить провайдера OpenID, а некоторые из пользовательских программ, которые мне нужно запускать для пользователей, могут быть настроены только для аутентификации через ODBC.
Еще одно предложение - FreeIPA http://freeipa.org/, но оно также несет дополнительную нагрузку на Kerberos и больше похоже на решение для уровня ОС. Он был в разработке в течение некоторого времени, но я не совсем уверен, что он достаточно зрелый, и у него также может быть слишком много ненужных функций, но при этом он не обеспечивает тех, которые мне действительно нужны.
Я хотел бы отделить хранилище данных аутентификации (имена пользователей и пароли) от сервиса аутентификации. Я бы использовал одно, четко определенное и безопасное местоположение для хранения данных и несколько служб аутентификации, которые используют место хранения для обеспечения аутентификации с использованием различных протоколов / интерфейсов. Необходим как минимум LDAP и интерфейс SQL, и поставщик OpenID также занимает высокое место в списке. Я думаю, что LDAP - хороший кандидат на хранение, но я открыт и для других вариантов. Желательно, чтобы они были свободными / открытыми.
Вопрос: Какое программное обеспечение выбрать для хранения учетных данных для проверки подлинности и как предоставить различные интерфейсы для проверки подлинности на основе этих учетных данных?
Какие у вас есть рекомендации?
1 ответ
Если вы используете LDAP в качестве резервного хранилища для учетных данных, то:
- Ты можешь использовать
pam_ldap
для проверки подлинности на уровне системы. - Многие базы данных могут проходить аутентификацию напрямую по LDAP (например, Postgresql)
- Другие базы данных могут использовать
PAM
, так что действует как ваш мост к LDAP. - Многие устройства и веб-приложения уже знают, как общаться с LDAP.
- Существуют модули LDAP для Apache и других веб-серверов.
Это, кажется, покрывает все ваши требования (если это не так, приведите несколько явных примеров). Для OpenID существует ряд решений, некоторые из которых (например, Atlassian Crowd) могут аутентифицироваться по LDAP и другие, которые могут использовать базовую аутентификацию HTTP (что означает, что вы будете охвачены модулями LDAP для Apache).
Кстати, выгода для Kerberos заключается не только в едином входе. Другое преимущество заключается в том, что при правильном использовании ваш пароль никогда не пересекает сеть. Это означает, что взломанный сервер не может собирать пароли. Это большое преимущество, но оно действительно полезно только в том случае, если (а) люди могут получать токены Kerberos из своей локальной конечной точки и (б) все ваши приложения поддерживают аутентификацию Kerberos или GSSAPI. В редких случаях вы можете фактически удовлетворить оба критерия в гетерогенной среде.