Назад | Перейти на главную страницу

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

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

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

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

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

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

Насколько сегодня хорошая идея - делать это через LDAP? Может быть, OAuth лучше?

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

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

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

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

Существует множество клиентских библиотек CAS, доступных для большинства сред программирования, а встроенная поддержка CAS становится все более распространенной для приложений, используемых или продаваемых университетам. В дополнение к основному "Jasig CAS Server" доступно также несколько дополнительных серверов, включая Сервер Ruby CAS и модуль для 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 может измениться в будущем.