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

8

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

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

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

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

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

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

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

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

ldap authentication single-sign-on transient_loop
источник

Ответы:

13

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

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

Florin Asăvoaie
источник
2
На самом деле я как-то осознавал это различие, но вы сформулировали его очень четко и сжато, спасибо. Я буду гуглить об OAuth / LDAP как архитектуре единого входа, но если у вас есть какие-либо релевантные ссылки, которыми вы хотели бы поделиться - очень признателен.
transient_loop
1

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

Адам Франко
источник
ради полного раскрытия информации - возможно, стоит упомянуть, что вы связаны с данным проектом
Journeyman Geek
Это справедливое замечание. Я связан с проектом CAS как пользователь и со-сопровождающий клиентской библиотеки PHP для системы phpCAS. Я подал несколько отчетов об ошибках и исправлений в основной проект, но я не верю, что они были фактически интегрированы в проект CAS.
Адам Франко