Я пытаюсь спланировать и реализовать решение SSO в корпоративной среде, которая обслуживает веб-приложения интрасети, работающие на CentOS:
Аутентификация успешно реализована в Active Directory через LDAP, так как эти приложения поддерживаются либо из коробки, либо с помощью плагина.
Поскольку для всех перечисленных выше веб-приложений не существует стабильного собственного плагина или модуля SSO, я склоняюсь к развертыванию Shibboleth в качестве поставщика удостоверений и решения SSO. Поскольку я не уверен, подходит ли это для данной ситуации, я хочу спросить следующее:
Active Directory <= Учетные данные домена <= Шибболет => Identity => Вход в приложение
Поставщик удостоверений (IdP) обрабатывает аутентификацию в базе данных или сервере LDAP и передает информацию о пользователе приложению = поставщику услуг (SP).
Я предполагаю, что вы имеете в виду использование реализации поставщика услуг, предоставленной создателями Shibboleth (получившего название shibboleth-sp), в разговоре с поставщиком идентификационной информации Shibboleth.
Это работает путем указания ресурсов, которые необходимо защитить, в конфигурации веб-сервера и дополнения параметров, передаваемых приложению, атрибутами, запрошенными поставщиком услуг IdP. Указанные атрибуты должны быть переданы 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