After ongoing POC testing, and the intention to turn shibd into an IdP plugin, this is overtaken by events. In particular, I've been able to take down the TCP gateway they implemented by simply running an nmap port check on a Mac. There's a call deep inside the Java socket code that does a set of the TCP_NO_DELAY option that appears to throw on a Mac (no idea if it's only Mac), so the gateway is not robust as it stands.

With the complexity of securing a socket link and the message framing, work thread pool, and many other challenges, it's clearly better to just use HTTP. The Apache agent will most likely just have to implement a wrapper around Windows' HTTP client and curl everywhere else to get enough functionality to use, but the HTTP client requirements will be kept as minimal as possible to avoid complicating it all.

The IdP obviously already provides the server half of this, so it's madness at this stage to do all that differently.

The original desire was for more compatibility with the current SP code and because it was intended to be stand-alone but those goals are not worth the work.

Outstanding issues:

• NIO just doesn’t seem to allow the standard gateway to work, it doesn’t find the connection to use for the response. I tried manually creating the output message with the connection ID header intact and it didn’t help.

• I tried using a channel interceptor to enforce client address rules. That works, but raising an exception there doesn’t make it to the error channel. That isn’t entirely a problem since arguably just dropping the connection might be the right thing to do, but it also precludes access to the client address later for logging. Moving to a Message<DDF> input parameter on the activator method allowed me to move that checking into the activator natively, and that allows the address to be captured for logging later at the cost of making the activator Spring Integration aware.

• I haven’t fully tested what the implications of the current CRLF message “demarcation” approach will actually mean for long-lived connections. The SP to this point has been length-prefixed, so I tested using the alternate message serializer that does that and it seemed to work. It’s easier to mock messages using the CRLF approach so I wired a property in that allows either and left it doing CRLF for now, but production/default use will probably be via prefixing the length.

Supposedly Java 17 has Unix domain socket support (which I see was noted in the issue, sorry), I don’t think Spring Integration has a gateway for that yet. We may want to build that if it’s not a ton of effort.

Aside from that issue, this all looks pretty clean to me. None of the other limitations I read about seem to be a concern. There’s no need to sequence messages that come in from separate connections and any given connection should be used by one client thread at a time to make a request and get a response before any other messages would come in. That fits all the default assumptions.

Given that we can wire all this up easily with a standard Spring approach that will let us reuse everything we have now in the IdP, I can’t see a good reason not to go down this path for now. We can certainly pull in our other Spring ApplicationContext customizations if we want. We might want to wrap the whole thing in a ReloadableService abstraction around the request/response layer so the whole underlying configuration would be reloadable.

Essentially nothing but the core messaging beans would be in the global/root context, and everything else in a child. The activation service can be built to invoke a bean that’s injected as the ReloadableService to call into and do the checkout/return semantic for the locking just like we do for various services now.

I checked out the spring-socket-server and did a bit of playing and reading. So far the one thing I couldn’t seem to do was make NIO work, which seems to be the desirable state of affairs I think (the docs suggest that decouples the request threads from the socket handling, which will help avoid some of the problems we have now).

But if I set use_nio=”true” in the three example gateway designs, it breaks the message correlation, and if I try and fix that, it seems to break the automatic type conversion that the explicit output channel definitions are providing.

I guess the goal would be to somehow solve that. It talks about message headers and how to achieve message correlation when there’s a separate output channel, but I can’t see where that all lines up with the way the service activation is generic and unaware of any of the Spring Integration code.