SP under IIS with TCP connection to shibd socket errors

[Paul Henson]

On 7/8/2022 11:55 AM, Cantor, Scott via users wrote:
> You're welcome to file patches with any improvements you want to 
> make, though at present I don't have any plans for any further SP 
> releases.

Anybody can file patches :), but obviously not all of them will be 
accepted. I usually try to get a feel for whether what I'm trying to do 
is something with a good chance of inclusion before I spend too much 
effort on it, although these changes are so minor wrapping them up in a 
request ticket won't be much more work than just making the changes in 
the first place.

I see the timeline for a possible release of SP v4 is 2024-2025, so I 
think it very unlikely that no security or packaging issue will pop up 
between now and then requiring a minor update release 8-/. But I suppose 
that an emergency release like that is not a planned release. But still 
an opportunity for minor changes like this to be let out into the wild ;).

> I don't know how much time it's worth spending debugging something  > that can't scale and isn't supported to begin with.

Hmm, I know that such a configuration is not very common and not 
recommended, but I don't recall having ever heard it wasn't supported? 
In particular, the current wiki page on clustering:

	https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334324/Clustering

has a section labeled "shared process" which certainly makes it appear 
it is supported (again, if not recommended):

* While the SP installation requires that you install both halves on
   each machine, you don't actually have to use both halves on each
   server.

* you can utilize a TCP connection to connect a number of web servers
   running the SP to a single shibd "listener" process

* this is likely to be viable

while the page does include a number of reasons why you shouldn't do it, 
there is nothing on it to imply you can't do it or that doing it would 
be completely unsupported if for some reason you had a use case that it met.

> The TCP support was due to the lack of domain sockets on Windows, it
> was never there to support separating the processes, but I'm sure
> you're aware.

If it was only ever supposed to talk to localhost, you guys shouldn't 
have made the remote address configurable :), if something can be done 
there's always somebody that will do it.

> The only historical reason for doing this was obviated by the cookie 
> session recovery feature, BTW.

I wasn't involved in the initial design/architecture of this particular 
deployment, I'm just looking into the sporadic failures. My gut feeling 
is that it is some Windows idiosyncrasy that is making it think it 
failed when actually it didn't and it should have tried again, but until 
I get some more detailed logging in place I can't say for sure.

Thanks for the info…


-- 
Signet - The Art of Access
https://www.signet.id/