Рекомендуется ли сегодня единый вход в LDAP для интеграции инструментов с открытым исходным кодом?

Мы проводим учения с государственным учреждением, чтобы установить различные инструменты с открытым исходным кодом, чтобы они могли экспериментировать и посмотреть, что подходит им больше всего.

Таким образом, мы устанавливаем:

• вики (докувики)
• mediagoblin
• гну социальная
• EtherPad
• ethercalc

и, возможно, еще немного.

Мы думали об использовании LDAP для согласования имен входа.

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

Сегодня все еще хорошая идея сделать это через LDAP? Возможно, OAuth - лучший выбор?

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

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

OAuth - это просто протокол для входа в систему, и он может использовать LDAP в качестве бэкэнда для управления пользователями.

В университетском мире система CAS Apereo [ранее Jasig] является распространенным способом единого входа для больших наборов веб-приложений. С помощью CAS пользователь только вводит свой пароль на сервере аутентификации - отдельные приложения проверяют одноразовый билет вместо просмотра пароля пользователя. Это главный выигрыш в безопасности при работе с приложениями, разработанными многими внутренними группами и поставщиками, поскольку ни одно из приложений никогда не имеет доступа к паролям пользователей.

Существует множество библиотек CAS-клиентов, доступных для большинства сред программирования, и встроенная поддержка CAS становится все более распространенной для приложений, используемых или продаваемых университетам. В дополнение к основному «Jasig CAS Server» есть также несколько дополнительных доступных серверов, включая Ruby CAS Server и модуль для Drupal, который может выступать в качестве сервера CAS для аутентификации дополнительных приложений в базе данных Drupal.

Сам Jasig CAS Server написан на Java и может быть поддержан любым количеством обработчиков аутентификации , включая:

• База данных
• JAAS
• LDAP
• наследие
• OAuth 1.0 / 2.0, OpenID
• РАДИУС
• SPNEGO (Windows)
• Доверенный (REMOTE_USER)
• X.509 (клиентский SSL-сертификат)

Сервер Jasig CAS может выступать в качестве источника аутентификации для приложения через ряд различных протоколов, используемых для единого входа:

• Протокол CAS 1/2/3
• Протокол SAML 1.1 / 2.0
• Протокол OAuth
• Протокол OpenId

Его можно даже использовать в качестве аутентификации за провайдером Shibboleth или использовать клиент Shibboleth в качестве сервера аутентификации.

Примечание: организация Jasig объединяется с организацией Apereo, поэтому некоторые URL-адреса могут измениться в будущем.