Корпоративный единый вход в интрасеть для веб-приложений против Active Directory
Я пытаюсь спланировать и внедрить решение единого входа в корпоративной среде, которая обслуживает веб-приложения интрасети, работающие на CentOS:
- Корпоративный портал (бэкэнд Drupal)
- Управление проектами (Project.NET)
- Система совместной работы с документами (Alfresco)
- Служба поддержки (Redmine)
- Отслеживание проблем (Atlassian Jira)
Аутентификация успешно реализована для Active Directory через LDAP, так как есть поддержка этих приложений либо из коробки, либо с помощью плагина.
Учитывая, что не существует стабильного собственного плагина SSO или модуля для всех вышеперечисленных веб-приложений, я склоняюсь к развертыванию Shibboleth в качестве провайдера идентификации и решения SSO. Поскольку я не уверен, подходит ли это для данной ситуации, я хочу спросить следующее:
- Подходит ли Shibboleth в качестве промежуточного звена для обеспечения входа в систему единого входа в этой схеме:
Active Directory <= учетные данные домена <= Shibboleth => удостоверение => вход в приложение
- Насколько я знаю, аутентификация, предоставляемая Shibboleth приложению, на самом деле достигается посредством конфигурации веб-сервера (Apache, Tomcat и т. Д.). Этот тип аутентификации предоставляет только разрешение на просмотр содержимого данной страницы, или он может полностью интегрироваться с аутентификацией приложения (как работает аутентификация LDAP)?
- Если вышеуказанный логин действительно работает, функции приложения для аутентифицированного пользователя все равно будут работать так, как если бы пользователь обычно входил в систему со своими учетными данными домена? (Например, Redmine поддерживает создание учетной записи "на лету" для успешного входа пользователя в первый домен).
1 ответ
Identity Provider (IdP) обрабатывает аутентификацию на базе данных или сервере LDAP и передает информацию о пользователе в приложение = Service Provider (SP).
Я предполагаю, что вы имеете в виду использование реализации Service Provider, предоставленной создателями Shibboleth (dubbed shibboleth-sp), для общения с IdP Shibboleth.
Это работает путем указания того, какие ресурсы необходимо защитить в конфигурации веб-сервера, и увеличения параметров, передаваемых приложению, с помощью атрибутов, запрошенных у IdP SP. Указанные атрибуты должны быть переданы IdP запрашивающему SP (attribute-filter.xml) и должны что-то значить для приложения. IdP не осуществляет контроль доступа, приложение должно решить, как оно интерпретирует параметры, полученные от IdP.
Таким образом, у вас либо есть приложение, которое может напрямую взаимодействовать с IdP (через SAML2, например, Liferay EE), либо вы используете shibboleth-sp и используете атрибуты для сопоставления пользователя с моделью ролей приложения.
Основной случай будет аналогичен использованию HTTP-аутентификации, отключению аутентификации в приложении и использованию параметра REMOTE_USER для идентификации пользователя. Дополнительные данные могут быть извлечены приложением в его хранилищах данных.
Обзор: http://predic8.com/shibboleth-web-services-sso-en.htm