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

Apache «Требовать действительного пользователя» действителен для нескольких типов аутентификации.

Наш 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