Мне удалось получить Shibboleth с SecureAuth, работающим на сервере IIS, на котором размещен простой index.html, а затем и простое приложение ASP.net MVC 4, оба из которых отлично работают.
Однако сегодня я попытался просто указать в своем приложении на новое приложение ASP.net CORE. Все, что я сделал, это сменил каталог в IIS, ничего особенного. Я установил на сервере хостинг .NET Core, и он работает (приложение работает и загружается нормально), пока мне не понадобится повторно пройти аутентификацию с помощью SecureAuth. В этом случае https://mywebsite.com/Shibboleth.sso/SAML2/POST в итоге получается 404 вместо 200. Моя первая мысль - это WebConfig, о котором я очень мало знаю. Вот старый, и Вот - это новый шаблон, оба без изменений по сравнению с шаблонами по умолчанию в Visual Studio 2015.
Есть ли какая-то дополнительная конфигурация сервера, которую нужно продолжить, или есть странный обработчик в этом WebConfig, который запускает неопределенное поведение? Shibboleth для меня новичок, так что расслабьтесь!
Изменить: некоторые дополнительные сведения ... В версии 8 IIS я настроил ограничения ISAPI и CGI, фильтр ISAPI и сопоставления обработчиков (снял флажок «Вызывать обработчик, только если запрос сопоставлен с ...»), чтобы указать на Shibboleth DLL. Все мои файлы конфигурации Shibboleth отлично работали и со старыми приложениями, поэтому я не понимаю, как это могло быть.
Я заметил, что ваши файлы 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-адрес службы потребителей утверждений
Итак, если в вашем случае все, что вы сделали, это
Тогда, скорее всего, на вашем развернутом веб-сайте будет отсутствовать конфигурация обработчика.
Я предлагаю снова добавить фильтр (используя пользовательский интерфейс ISS) и скопировать сгенерированную конфигурацию обработчика в ваш проект web.config (чтобы вы не потеряли его снова)
IIS, шибболет и пустельга
Это не прямой ответ на ваш вопрос, а краткое изложение того, как они взаимодействуют (общая картина - может помочь в дальнейшем устранении неполадок)
Основное отличие от «обычного» приложения 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 и аутентификации вашим ACS shibboleth - другими словами: на этот раз запрос возвращается с действующим файлом cookie сеанса shibboleth)
Из того, что мне удалось найти, .NET Core плохо работает с Shibboleth из-за того, как он использует IIS (в качестве прокси), и из-за отсутствия управляемого кода. Поскольку Shibboleth работает как фильтр ISAPI в IIS, а приложение .NET Core, вероятно, работает на собственном веб-сервере Kestrel, это не работает. Ресурс не найден, потому что адрес http: //.../Shibboleth.sso/login не существует в контексте Kestrel.