NativeSPOneMany

People often want to save themselves from the supposed cost of installing the SP on multiple web servers and ask whether a single SP installation can somehow "protect" many web servers. This is physically impossible apart from using one web server as a proxy to others; in such a case no secured application traffic can flow directly to the proxied servers, which really makes them no more than an implementation detail to the proxying server; this is a "solution", but not usually one that will scale to hundreds of servers.

No form of HTTP authentication can be implemented without code living in or behind the web server hosting the protected resource, except in the case noted above, reverse proxies or concentrators that act as front-ends. Usually the latter approach is only used to offload SSL processing, and still requires authentication code running on each back-end server, but not always. Reverse proxies, OTOH, tend to actually isolate the authentication solution to a single front-end, but at a cost in usability and manageability.

If you can't deploy an SP on the relevant web servers, then you will have to deploy something else in its place. You can combine that something else with SAML by connecting that solution with an SP and constructing a gateway to/from the additional authentication protocol. You are responsible for glueing that together and making it work. The software will neither help nor hinder you.

See also a description of the general application model that underlies the software to understand better how deployment of the SP works and what it does well and not well.