Shibboleth 404 при обновлении до ASP.net CORE
Мне удалось получить Shibboleth с SecureAuth, работающим на сервере IIS, на котором размещен простой index.html, а затем и простое приложение ASP.net MVC 4, оба из которых отлично работают.
Сегодня я попытался просто сделать свой app указывает на новое приложение ASP.net CORE. Все, что я сделал, это сменил каталог в IIS, ничего особенного. Я установил на сервере хостинг .NET Core, и он работает (приложение работает и загружается нормально), пока мне не понадобится повторно пройти аутентификацию с помощью SecureAuth. В этом случае https://mywebsite.com/Shibboleth.sso/SAML2/POST в конце дает 404 вместо 200. Моя первая мысль - это WebConfig, о котором я очень мало знаю около. Здесь - старый, а здесь - новый, оба неизменны по сравнению с шаблонами по умолчанию в Visual Studio 2015.
Есть ли какие-то дополнительные настройки сервера, которые нужно продолжить, или есть странный обработчик в этом WebConfig, который запускает неопределенное поведение? Shibboleth для меня новичок, так что не беспокойтесь!
Edit: Некоторые дополнительные сведения ... В IIS версии 8 я настроил ограничения ISAPI и CGI, фильтр ISAPI и сопоставления обработчиков (не отмечен флажок «Вызывать обработчик, только если запрос сопоставлен с ... "), чтобы указать на DLL Shibboleth. Все мои файлы конфигурации Shibboleth отлично работали и со старыми приложениями, поэтому я не понимаю, как это могло быть.
Из того, что мне удалось найти, .NET Core не работает с Shibboleth из-за того, как он использует IIS ( в качестве прокси) и тот факт, что управляемый код недоступен. Поскольку Shibboleth работает как фильтр ISAPI в IIS, а приложение .NET Core, вероятно, работает на собственном веб-сервере Kestrel, это не работает. Ресурс не найден, так как адрес http: //.../Shibboleth.sso/login не существует в контексте Kestrel.
Я заметил, что ваши файлы web.config не содержат никакой конфигурации shibboleth, например, часть обработчика:
<add name="ShibbolethEndPoints" path="*.sso" verb="*" modules="IsapiModule" scriptProcessor="C:\opt\shibboleth-sp\lib64\shibboleth\isapi_shib.dll" resourceType="Unspecified" preCondition="bitness64" />
Когда я выполнил свою первоначальную настройку (с использованием интерфейса IIS), чтобы добавить обработчик, эта строка была добавлена в мой файл web.config.
Если я позже разверну новую версию своего приложения, web.config будет перезаписан, и я получу ошибку 404 (потому что действительно нет ничего, чтобы понять Утверждение URL-адрес службы потребителей
Итак, если в вашем случае все, что вы сделали, это
- развернули новое приложение в новой папке (с 'новым' web.config, как указано в вопросе)
- и указали на ваш существующий сайт в новую папку
Тогда, скорее всего, конфигурация обработчика будет отсутствовать на вашем развернутом веб-сайте.
Я предлагаю снова добавить фильтр (используя пользовательский интерфейс ISS) и скопировать сгенерированную конфигурацию обработчика в ваш проект web.config (чтобы вы не потеряли его снова)
IIS, shibboleth и Kestrel
Это не в прямых ответах Отвечая на ваш вопрос, но краткое изложение того, как они взаимодействуют (общая картина - может помочь в дальнейшем устранении неполадок)
Основное отличие от «обычного» приложения ASP.NET состоит в том, что IIS в основном представляет собой обратный прокси-сервер, расположенный перед Kestrel .
Однако это не влияет на поток Shibboleth. Предположим, вы настроили shibboleth для защиты www.example.com/ressources как обычно (ничего особенного для ядра asp.net)
Если вы запрашиваете www.example.com/ressources/index.html: shibboleth перехватывает запрос, и запускает поток аутентификации с IDP
. Позже, когда вы будете перенаправлены обратно на www.example.com/ressources/index.html (после идентификации IdP и аутентификации вашим shibboleth ACS - другими словами: на этот раз запрос возвращается с действительным файлом cookie сеанса shibboleth)
- shibboleth все еще перехватывает запрос, проверяет, является ли сеанс действительным, а затем пересылает его в IIS
- В свою очередь, «обратные прокси-серверы» IIS в Kestrel
- Kestrel обслуживают запрашиваемый ресурс (предполагается, что ваше приложение принимает идентификатор, который Shibboleth передает в заголовках HTTP).