The most confusing aspect of the SP software for beginners, aside from all the SAML and federation concepts, is how the software relates to the applications and resources it's being used to protect. Early use tends to lead to a lot of common questions:
...
Logical and Physical SPs
| Note |
|---|
A single installation of the SP software can act as many logical, distinct "services", and a single logical "service" can span any number of physical hosts. |
The first point to make is that the term "Service Provider" (SP) gets thrown around a lot in the documentation and in email, and sometimes it means slightly different things based on context. Like a lot of things in computing, there's the physical part (the software bits you're installing) and the logical part (the notion of a service).
...
The meat of the software configuration is divided across two sections of the shibboleth2.xml file: the <RequestMapper> and the <ApplicationDefaults> elements. In the case of Apache, the former is generally omitted in favor of Apache-specific commands.
Assigning Resources to Applications
...
With V3, there's a new setting, selfEntityIDentityIDSelf, which attacks the opposite problem, defining each virtual host as its own logical SP with a pattern-based entityID derived from the virtual host name. The goal is to eliminate as much as practical any need to define overrides at all.
...
One of the most common things when creating an override is to assign it a special entityID, making it a distinct logical SP living inside the same physical installation. This is done by adding an entityID property to the <ApplicationOverride> element. With V3, this can even be avoided by assigning each virtual host to a selfEntityID a entityIDSelf content setting that allows the system to derive its own name at runtime based on the virtual host accessed.
...