Shibboleth at NC State » Technical Documentation » Advanced SP Configuration » Running SPs at Scale

Running Service Providers at Scale

Concepts

One Host, One Service Provider

This is the simplest case. You have one webserver, running under one hostname, so you only need one SP Entity.

For example:

Load Balancing

You have a high-volume website running on a shared hostname, where connections are load-balanced among two or more servers. You still want to have only one SP Entity running on each server. The endpoints should match the load-balanced hostname, not the server names.

Note: Make sure your load balancing service supports persistence. That means it will always send a given client to the same server so long as that server is available. The SP software will maintain session information on each server independently of the others. If the client is sent to the wrong server, their session cookie will not be recognized.

SSL Offloading with Load Balancing

This is a specific case that we've had to resolve on campus. The Service Provider is running on a pair of real servers. The https://hostname url is handled by a NetScalar doing SSL Offloading. Connections to the SP are made through SSL to the netscalar, and then proxied over http without SSL to one of the real servers.

The real servers should have a shared entity and key-pair as described above. They should also be configured with handlerSSL="false" in the Sessions tag in shibboleth2.xml. This is because all of the network connections will be coming from the NetScalar over http, not https.

This causes a problem for the SP software. When it tries to generate the endpoints for a SAML request, it thinks it is running a non-SSL site, and so it will generate http://hostname endpoints. Those will not use the NetScalar correctly, and they will trigger an error with the POST- Forward step in the browser.

To resolve this problem, we need to tell Apache httpd that the ServerName must include https. Edit your httpd config file and locate the ServerName directive, either in httpd.conf or in a VirtualHost block. Change the name from a bare hostname to the https URL. For example:

# change from this:
ServerName www.yourhost.ncsu.edu
# to this:
ServerName https://www.yourhost.ncsu.edu

The httpd software should continue to run correctly. The SP software will use this ServerName when constructing the endpoint URLs, and so it will correctly direct the connections through the NetScalar.

Virtual Hosting

You have a single webserver, running multiple web hostnames using virtual hosting. You can chose to share an SP Entity among all of your hosts, or you can register individual SP Entities for each host.

Shared Entity

All of your hosts are related, perhaps by all being in the same department. They all have the same ARP requirements. You can share a single SP Entity among these hosts by enumerating the endpoints specific for each hostname.

See this document for information on how to bypass endpoint checks or this document on how to add additional endpoints to your metadata.

Individual Entities

Perhaps your hosts are not related. Or perhaps one of them needs more attributes than the others. In this case, it is possible to configure the one SP software instance to use more than one SP Entity based on the requesting path or based on an .htaccess configuration directive.

See this document for information on how to add additional endpoints to your metadata.

Other Permutations

Sharing an Entity on Different Servers

Different Application Requirements on a Single Host

Load-Balanced Virtual Hosting