title: IdentityServer3 - Cookie Path Issue
body: <p>My question is in regards to an issue with the cookies generated by an IIS hosted, IdentityServer 3 SSO application using OWIN WS-Federation middleware. We were experiencing an intermittent production issue which was preventing logins (and logouts) from occurring. While I have tracked down the cause, I believe that this makes our SSO vulnerable to attacks.</p>
  
  <p>IIS setup:</p>
  
  <ul>
  <li><code>https://www.example.com</code> - Parent App (Client Application)
  
  <ul>
  <li><code>login</code> - Sub-App (IDS3 app using OWIN WS-Federation Middleware)</li>
  </ul></li>
  </ul>
  
  <p>(Note: Other client apps exist, but they are on other servers)</p>
  
  <p>What we would expect to see out of a setup like this, is that Identity Server's cookies (idsrv, idsrv.external, idsrv.partial, and idsrv.session) should path out to "/login/core". Instead we were seeing some of those cookies (specifically, idsrv, idsrv.external, and idsrv.partial) path out to "/Login/core". I was finally able to track down the issue to a health check that was pinging our app every 30s in Prod, which had the wrong casing set up ("/Login/core"). </p>
  
  <p>It appears that when that health check was the initial request our SSO app received, the idsrv, idsrv.external, and idsrv.partial cookies would <strong>always</strong>, on all further requests - even from other clients, browsers, machines, etc. - get set to the incorrect "/Login/core" path up until the app was restarted.</p>
  
  <p><a href="https://i.stack.imgur.com/655Li.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/655Li.png" alt="enter image description here"></a></p>
  
  <p>What that means is that during the redirection for WS-Federation sign-in, all authentication information is lost due to the incorrect cookie paths. Despite seeing in the logs that the user is successfully authenticated, the user is not logged in (subject.Identity.IsAuthenticated returns false) and the log in page is rendered again without an error message.</p>
  
  <p>Oddly, the idsrv.session &amp; SignInMessage cookies are still set to the correct path even in that scenario, which I assume is because they are created at a different point in the authentication process. If a request from any of our client applications hits the SSO app first, the correct "/login/core" path is set for all cookies.</p>
  
  <p>Once I was able to figure out the root cause of the problem, it was simple to fix. My concern is that this is a pretty clear vulnerability, wherein someone intentionally or unintentionally (as in our case) could take down our SSO app if they manage to time their incorrectly cased request with an app recycle event or post-deploy. I'm curious if this is a limitation surrounding sub-apps hosted in IIS that's causing this, or if there is some other reason that this is occurring. Any insight as to how we can plug up the vulnerability (outside of hosting it as a sibling app) would be greatly appreciated.</p>