Наш Apache использует как mod_shib_24 (SAML-SP), так и mod_auth_openidc (OIDC-RP), которые оба подключены к Shibboleth IdP (действует как SAML-IDP и OIDC-OP).
Кроме того, у нас есть 2 защищенных местоположения, одно защищено SAML, другое - OIDC:
ShibCompatValidUser On
<Location "/">
Require shib-session
AuthType Shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
</Location>
<Location "/oidctest">
Require valid-user
AuthType openid-connect
</Location>
А теперь самое запутанное:
Если я получаю доступ к чему-либо, кроме / oidctest /, мне нужно войти в систему с использованием SAML (как и ожидалось, задействуется mod_shib_24), но после успешной аутентификации я также могу получить доступ к / oidctest / без необходимости аутентификации с помощью OIDC.
Это работает и наоборот. Если я получаю доступ к / oidctest / first (новое частное окно), мне нужно пройти аутентификацию с использованием OIDC (как и ожидалось, задействуется mod_auth_openidc), и после успешной аутентификации я также могу получить доступ ко всем другим местоположениям (кроме / oidctest /).
Итак, как Apache обрабатывает директивы действительных пользователей? Как в Apache определяется "действительный пользователь"?
Является ли пользователь действительным для всего после входа в систему, независимо от типа аутентификации, независимо от модуля, независимо от протокола?
Или это неожиданное поведение?
Насколько я понимаю из вики Shibboleth, ShibCompatValidUser On настройки явно предназначены для совместимости с требовать действительного пользователя заявления.
До V2.5.2 и когда ShibCompatValidUser выключен (по умолчанию), это эквивалентно правилу shib-session, приведенному выше. Когда опция ShibCompatValidUser включена, это правило реализуется совместно с правилом, реализованным самим Apache, и требует, чтобы для запроса было установлено ненулевое значение REMOTE_USER. Это восстанавливает возможность развертывания Shibboleth вместе с другими модулями и правилами. В будущей версии SP может быть удалено "специальное" определение, и такие правила должны быть изменены, чтобы полагаться на shib-session.
Видеть https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess
Чтобы различать модули, вы также можете использовать тесты с Требовать env для поиска переменных окружения, установленных модулем. Shibboleth по умолчанию устанавливает Shib-Session-ID например.
Видеть https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess