2

I managed to get Shibboleth with SecureAuth working on an IIS server hosting a simple index.html and later a simple ASP.net MVC 4 app, both of which work great.

Today, though, I tried simply making my app point to a new ASP.net CORE app. All I did was change the directory in IIS, nothing special. I installed .NET Core hosting on the server and it works (the app runs and loads just fine) until I need to re-authenticate with SecureAuth. In that case, the https://mywebsite.com/Shibboleth.sso/SAML2/POST at the end results in a 404 instead of a 200. My first thought is the WebConfig, which I know very little about. Here is the old one, and here is the new one, both unchanged from the default templates in Visual Studio 2015.

Is there any additional server configuration that needs to go on, or is there a weird handler in that WebConfig that is triggering undefined behavior? Shibboleth is new to me, so go easy!

Edit: Some extra details... On IIS version 8 I configured the ISAPI and CGI Restrictions, ISAPI Filter, and Handler Mappings (unchecked "Invoke handler only if request is mapped to...") to point to the Shibboleth DLL. All my Shibboleth configuration files worked fine with the old apps as well, so I don't see how it could be those.

TheSmartWon
  • 121
  • 4

2 Answers2

2

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).
EnjiLenin
  • 21
  • 2
1

From what I've been able to find, .NET Core doesn't work well with Shibboleth due to the way it uses IIS (as a proxy) and the fact that no managed code is available. Since Shibboleth runs as an ISAPI filter within IIS, and the .NET Core application is likely running within its own Kestrel web server, this doesn't work. The resource is not found because the address http://.../Shibboleth.sso/login doesn't exist in the context of Kestrel.

icastel
  • 11
  • 1