Iis – Downgrade ASP.NET Core Hosting Bundle 5 to 3.1 or install them side by side

1. Open IIS Manager
2. Expand the server name node
3. Select 'Sites'
4. On the 'Actions' section push 'Add Website...'
5. Set the 'Site name', 'Physical path', and the 'Binding' and push 'OK'. Notice that the DefaultAppPool in IIS8 is for Asp.Net4

The next step do the trick for IIS8:

6. Expand 'Default Web Site'. Your site name should be under.

7. Right click on you site name, and push 'Convert to Application'

That's it. Now it should work.

It took me three hours to find that right click -> convert to application thing... I hope this answer will save others time.

I notice that your web.config files do not contain any shibboleth configuration, for instance the handler part :

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

When I did my initial setup (using IIS UI) to add the handler, this line was added to my web.config file.

If I later deployed a new version of my application, web.config would be overwritten and I would end up with a 404 error (because indeed there is nothing to understand the Assertion Consumer Service URL

So if in your case all you did was to

• deployed the new application to the new folder (with the 'new' web.config as linked in the question)
• and pointed your existing site to the new folder

Then most likely the handler configuration is going to be missing on your deployed website.

I suggest to add the filter again (using the ISS UI), and to copy the generated handler configuration to you project's web.config (so that you do not loose it again)

IIS, shibboleth, and Kestrel

This is not in direct answer to your question, but quick summary on how they are interacting (the bigger picture - might help troubleshoot further)

The main difference to 'regular' ASP.NET application is that IIS is mostly a reverse proxy sitting in front of Kestrel.

This does not really impact the Shibboleth flow though. Let us assume you have configured shibboleth to protect www.example.com/ressources as usual (nothing specific to asp.net core)

If you request www.example.com/ressources/index.html: shibboleth intercepts the request, and triggers the authentication flow with the IDP

Later when you are redirected back to www.example.com/ressources/index.html (after being identified by the IdP, and authenticated by your shibboleth ACS - in other word : this time the request comes back with a valid shibboleth session cookie)

• shibboleth still intercepts the request, checks the session is valid, and then forwards to IIS
• In turn, IIS 'reverse proxies' to Kestrel
• Kestrel serves the requested ressource (assuming that your application accepts the identity which Shibboleth passes along in the HTTP headers).