Единая точка входа с LDAP все еще рекомендована сегодня интегрировать набор инструментов с открытым исходным кодом?
Мы ведем осуществление с государственным учреждением для установки различных инструментов с открытым исходным кодом для них, чтобы экспериментировать и видеть то, что удовлетворяет им больше всего.
Таким образом мы устанавливаем:
- Wiki (dokuwiki)
- mediagoblin
- социальная гну
- etherpad
- ethercalc
и возможно еще немного.
Мы думали об использовании LDAP для согласования логинов.
Но часто такое чувство, что плагины LDAP больше не сохраняются, и конфигурация является трудной хорошо работать, некоторые инструменты имеют недостаточные документы LDAP.
Это - все еще хорошая идея сегодня, чтобы сделать это через LDAP? OAuth является, возможно, лучшим выбором?
Я знаю, что это не вопрос о коде, но что мы хотели бы понять, то, если мы должны придерживаться нашего решения пойти LDAP или если мы должны рассмотреть другие пути.Большое спасибо
LDAP не может обеспечить единственный вход. Существует большая разница между возможностью использовать одних и тех же пользователей и однократным входом, что означает, что вы входите во все системы одновременно, с одной формой входа. В противном случае LDAP прекрасно подходит для использования одной и той же информации для входа во всех системах.
OAuth - это всего лишь протокол для выполнения Sign On, и он может использовать LDAP в качестве бэкэнда для управления пользователями.
.В университетском мире система Apereo [ранее Jasig] CAS является распространенным способом выполнения единого входа для больших наборов веб-приложений. В CAS пользователь вводит свой пароль только на сервере аутентификации - отдельные приложения проверяют одноразовый билет вместо того, чтобы видеть пароль пользователя. Это крупный выигрыш в области безопасности при работе с приложениями, разработанными многими внутренними группами и поставщиками, поскольку ни одно из приложений никогда не имеет доступа к паролям пользователей.
Существует множество клиентских библиотек CAS, доступных для большинства сред программирования и созданных. -в CAS становится все более распространенной поддержка приложений, используемых или продаваемых университетам. В дополнение к основному серверу Jasig CAS Server доступно несколько дополнительных серверов,включая Ruby CAS Server и модуль для Drupal , который может действовать как сервер CAS для аутентификации дополнительных приложений в базе данных Drupal.
Сам Jasig CAS Server написан на Java и могут поддерживаться любым количеством обработчиков аутентификации , включая:
- База данных
- JAAS
- LDAP
- Устаревшие
- OAuth 1.0 / 2.0, OpenID
- RADIUS
- 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-адреса могут измениться в будущем. д.