Сессия Shibboleth не авторизована
Мой опыт работы с Shibboleth ограничен, и у меня нет доступа к конфигурации или журналам на IdP или SP. Я пытаюсь устранить эту проблему:
Предыдущий сеанс Shibboleth все еще активен на клиентской рабочей станции. При попытке получить доступ к документу, защищенному следующей конфигурацией.htaccess:
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
Клиент (иногда) получает следующее сообщение об ошибке:
Authorization Failed
Based on the information provided to this application about you, you are not authorized to access the resource at "http://myresourcepath"
Please contact the administrator of this service or application if you believe this to be an error
При устранении неполадок я изменил.htaccess с
require valid-user
чтобы:
require shib-session
Я думал, что проблема может быть устаревшим параметром, но после изменения я все еще получал сообщение об ошибке авторизации. Единственный способ успешно авторизоваться - это очистить кеш браузера, вернуться на страницу, на которой он запрашивает аутентификацию, и авторизация пройдет проверку, и вы успешно попадете на страницу без ошибок.
Что еще больше осложняет ситуацию, так это когда.htaccess имеет значение:
require shib-session
Сообщение об ошибке авторизации сохраняется даже после очистки кеша и повторной аутентификации. Я должен был изменить.htaccess обратно на
require valid-user
Я не знаю, что может вызвать случайную проблему авторизации, если сеанс был недействительным, пользователь будет перенаправлен на idp для входа, правильно? Это дизайн Шибболет. Итак, сеанс должен быть действительным, но почему он не распознает пользователя как авторизованного для этого ресурса?
Дополнительно:
после того, как я получил сообщение и быстро погуглил, похоже на стандартный ответ от idp:
https://technical.bestgrid.org/index.php/Vladimir's_general_Shiboleth_notes
говорит:
В этом конкретном примере запрашивается, чтобы для пользовательской переменной было задано любое значение, и любой атрибут Shibboleth можно использовать с именем переменной, которому он назначен в политике принятия атрибутов (AAP.xml). Дополнительный синтаксис использования директивы require см. В примерах документации по SP htaccess SP, посвященных конкретным функциям, реализованным для директивы Apache require. Пользователи, которые не имеют атрибута (или не предоставляют его), получают следующее сообщение об ошибке (с логотипом Shibboleth). .... это же сообщение....
Эта форма контроля, однако, может быть не такой удобной для пользователя - пользователь должен знать, что нужно либо использовать Autograph, чтобы разрешить выпуск атрибута, либо поговорить со своим администратором IdP, чтобы настроить атрибуты на IdP. Также обратите внимание, что это не работает с ленивыми сессиями - в этом случае сразу же появляется то же сообщение об ошибке. Кроме того, обратите внимание, что необходимо соблюдать осторожность с перекрывающимися блоками контроля доступа. Они должны быть перечислены от самых общих ("/") до самых конкретных (как "/secure" в приведенном выше примере). В противном случае более расслабленные настройки в общем будут переопределять более строгие настройки в конкретном.