Shibboleth 404 ao atualizar para o ASP.NET CORE

Question

Consegui obter o Shibboleth com SecureAuth trabalhando em um servidor IIS hospedando um simples index.html e depois um simples aplicativo ASP.net MVC 4, ambos funcionando muito bem.

Hoje, porém, tentei simplesmente fazer com que meu aplicativo apontasse para um novo aplicativo ASP.NET CORE. Tudo que fiz foi mudar o diretório no IIS, nada de especial. Eu instalei o .NET Core hosting no servidor e ele funciona (o aplicativo é executado e carrega muito bem) até que eu precise autenticar novamente com o SecureAuth. Nesse caso, o link no final resulta em um 404 em vez de um 200. Meu primeiro pensamento é o WebConfig , sobre o qual eu sei muito pouco. Aqui é o antigo e aqui é o novo, ambos inalterados dos modelos padrão no Visual Studio 2015.

Existe alguma configuração adicional do servidor que precisa continuar, ou há um manipulador estranho nesse WebConfig que está acionando um comportamento indefinido? Shibboleth é novo para mim, então vá devagar!

Editar: Alguns detalhes adicionais ... No IIS versão 8, configurei as Restrições ISAPI e CGI, o Filtro ISAPI e os Mapeamentos do Manipulador (desmarque "Invocar manipulador somente se a solicitação estiver mapeada para ...") para apontar para o Shibboleth DLL. Todos os meus arquivos de configuração do Shibboleth funcionaram bem com os aplicativos antigos também, então não vejo como poderiam ser esses.

    

Answer 1

Percebo que seus arquivos web.config não contêm nenhuma configuração shibboleth, por exemplo, a parte do manipulador:

      <add name="ShibbolethEndPoints" path="*.sso" verb="*" modules="IsapiModule" scriptProcessor="C:\opt\shibboleth-sp\lib64\shibboleth\isapi_shib.dll" resourceType="Unspecified" preCondition="bitness64" />

Quando fiz minha configuração inicial (usando a interface do usuário do IIS) para adicionar o manipulador, esta linha foi adicionada ao meu arquivo web.config.

Se mais tarde eu implantasse uma nova versão do meu aplicativo, o web.config seria substituído e eu terminaria com um erro 404 (porque de fato não há nada para entender a URL do Assertion Consumer Service

Então, no seu caso, tudo que você fez foi

• implantou o novo aplicativo na nova pasta (com o 'novo' web.config vinculado à pergunta)
• e apontou seu site existente para a nova pasta

Então, muito provavelmente, a configuração do manipulador estará ausente em seu site implantado.

Sugiro adicionar o filtro novamente (usando a interface do usuário do ISS) e copiar a configuração do manipulador gerado para o web.config do projeto (para que você não o perca novamente)

IIS, shibboleth e Kestrel

Isso não está na resposta direta à sua pergunta, mas um rápido resumo sobre como eles estão interagindo (a foto maior - pode ajudar a solucionar mais)

A principal diferença para o aplicativo ASP.NET 'regular' é que o IIS é principalmente um proxy reverso na frente do Kestrel.

Isso não afeta realmente o fluxo do Shibboleth. Vamos supor que você tenha configurado o shibboleth para proteger www.example.com/ressources como de costume (nada específico para o núcleo do asp.net)

Se você solicitar www.example.com/ressources/index.html: o shibboleth intercepta a solicitação e aciona o fluxo de autenticação com o IDP

Mais tarde, quando você for redirecionado para www.example.com/ressources/index.html (depois de ser identificado pelo IdP e autenticado pelo seu ACS shibboleth - em outras palavras: desta vez, a solicitação voltará com um shibboleth válido cookie de sessão)

• O shibboleth ainda intercepta a solicitação, verifica se a sessão é válida e encaminha para o IIS
• Por sua vez, os 'proxies reversos' do IIS para o Kestrel
• O Kestrel atende ao recurso solicitado (supondo que seu aplicativo aceite a identidade que o Shibboleth transmite nos cabeçalhos HTTP).

Answer 2

Pelo que consegui encontrar, o .NET Core não funciona bem com o Shibboleth devido à maneira como ele usa o IIS (como proxy) e pelo fato de não haver código gerenciado disponível. Como o Shibboleth é executado como um filtro ISAPI no IIS, e o aplicativo .NET Core provavelmente está sendo executado em seu próprio servidor Web Kestrel, isso não funciona. O recurso não foi encontrado porque o endereço link não existe no contexto do Kestrel.