SP Address Checking From Web Server as Source

[Steven Teixeira]

Thanks for the reply, Scott.

> I don't know that one would want the SP "protecting" such requests, you wouldn't want to be messing with trying to get the client's cookies to be sent with such loopback requests. Not requiring a session isn't far enough, you want it excluded entirely and rely on IP rules for access I'd expect.

Agreed that this is messy.  There is propagation of cookies based on the type of request, and we've tried including and excluding _shibsession to no success.  If it's included, it most certainly will be seen as a mismatch, and if it's excluded, the handler will see the request as unauthenticated and attempt to take action anyway.  It does seem that the application does at least see the _shibsession cookie at some point though, because the mismatch triggers no matter what.  The application itself gives a token on successful authentication, and that's passed in requests, but the handler doesn't care about it and doesn't know the difference.

> It isn't. A single range would have to encompass both the client network(s) and localhost, which is I would think impossible other than by making all network ranges unreliable, equivalent to disabling it.

Thanks also for confirming what I suspected about the unreliableNetworks attribute.  I also thought that you'd essentially have to put every range for this to work, which is just the equivalent of setting consistentAddress to false and I'm trying to avoid that.  Another question though...is there any other risk that's being mitigated by the consistentAddress attribute on the Sessions element other than a _shibsession cookie being stolen from a compromised client?  If the transport channel is https, can the _shibsession cookie be forged any other way than extracting it from the browser?

> you can file a RFE against the replacement project

Yes, server to server communication is not necessarily the use case for the SP.  However, now that .NET is more agnostic (to the point of ignoring what has traditionally been available to the web server to manage and be responsible for), and seems to have these interesting new hosting models, I'm wondering how much more this may be an issue over time as more developers start approaching .NET Core.  Since we may be one of the first to experience this new scenario, and I don’t' really know how likely this will come up in the future, I'm inclined not to open an RFE for now.  I'd rather not add to a feature list if we're really the only ones who will experience this sort of issue, especially if it's for something that's a long time off anyway.  Thanks again for your time.

Steven Teixeira