Apache «require valid-user» действителен для нескольких типов аутентификации

Apache «require valid-user» действителен для нескольких типов аутентификации

Наш 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/ (новое приватное окно), мне нужно пройти аутентификацию с использованием OIDC (mod_auth_openidc, как и ожидалось, вмешивается), и после успешной аутентификации я также могу получить доступ ко всем другим местоположениям (кроме /oidctest/).

Так как же Apache обрабатывает директивы valid-user? Как определяется "valid-user" в Apache?

Является ли пользователь действительным для всех действий после входа в систему, независимо от типа аутентификации, модуля и протокола?

Или это неожиданное поведение?

решение1

Насколько я понимаю из Shibboleth wiki,ShibCompatValidUser Вкл.настройки явно предназначены для совместимости стребуется действительный пользовательзаявления.

До версии 2.5.2, и когда ShibCompatValidUser выключен (по умолчанию), это эквивалентно правилу shib-session выше. Когда опция ShibCompatValidUser включена, это правило реализуется совместимо с правилом, реализованным самим Apache, и требует установки ненулевого значения REMOTE_USER для запроса. Это восстанавливает возможность развертывания Shibboleth вместе с другими модулями и правилами. Будущая версия SP может удалить определение «special», и такие правила следует изменить, чтобы они полагались на shib-session.

Видетьhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess

Чтобы различать модули, вы также можете использовать тесты сТребовать окружениядля поиска переменных окружения, установленных модулем. Shibboleth по умолчанию устанавливаетShib-Session-IDнапример.

Видетьhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess

Связанный контент