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

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

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

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

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

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

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

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

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

Источник

2 ответа

Решение

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-адреса могут измениться в будущем.

Источник
Другие вопросы по тегам