Page Comparison

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

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).

...

...

• It acts as a barrier between user sessions managed by the software, such that a session with one application will not be shared with other applications. Crossing an application boundary between requests results in separate round trips to the IdP, separate assertions created, and separate attributes cached. It may or may not result in a separate login; that's mostly up to the IdP (assuming the SP doesn't request forced re-authentication).

• It is usually associated with one (and only one )  logical SP. To the outside world, the application is part of that SP, named by its entityID, and is not meant to be distinguished from any other part of that logical SP. With V3, a bit more flexibility is supported, in that an application may polymorphically assign itself different entityIDs at runtime, typically based on the virtual host. This is a new feature that avoids the need for defining multiple applications to support a one-SP-per-vhost scenario, common to virtual hosting platforms. It doesn't avoid the need for metadata for each SP, but it reduces the amount of SP configuration required.

• It uses a common configuration for all of the SAML-related behavior the software carries out, such as metadata and trust, security policy, attribute processing, etc (save for the multiple entityID feature noted in the prior bullet point).

• It includes one or more unique handlerURL locations that are a unique handlerURL location specific to the application and are associated only with it. Requests to SP handlers, such as Assertion Consumer Services and Session Initiators, are always prefixed with this URL and are grouped together into the set of resources that make up the application. Usually this URL will contain the path /Shibboleth.sso. There is usually only a single such URL, but if an application spans multiple virtual hosts, then each of those virtual hosts will have its own (usually automatically generated) handlerURL.

...

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.

...

Referring to earlier discussion, the SP software cannot generally rely on the web server alone to make the essential determination at runtime about which application a given resource belongs to. Instead, the software requires that you, the deployer, make that determination by associating a content setting called applicationId with each request, provided that you intend there to be more than one (otherwise you would simply leave everything bound to the default behavior).

The details are described here, but in general this is done by either of:

...

It's a good idea to review the NativeSPContentSettingsContentSettings topic, because you'll find a variety of useful settings there that in some cases historically required defining multiple applications to the SP software in order to use.

For example, it used to be common to use multiple applications to hard-wire different virtual hosts or directories to use particular IdPs. This is not needed; you can simply define an entityID property based on the content, without needing the overhead of defining additional applications and complicating the SP's metadata.

With V3, there's a new setting, selfEntityID, 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.

Application Configuration

Once you assign a non-default applicationId property to some set of content, you have to complete the configuration by defining an "application override" in the shibboleth2.xml file. Defining a new application requires the minimum of an <ApplicationOverride> element just inside the closing </ApplicationDefaults> tag. An id attribute is needed with the applicationId used in the resource mapping step above. The rest depends on what's intended to be different about the application from the default settings.

...

One of the most common things you'll do 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 content setting that allows the system to derive its own name at runtime based on the virtual host accessed.

The other common task depends on whether the application is intended to take up the whole of a different virtual host, or is part of a web tree on a virtual host that includes multiple applications. Separation by virtual host is the recommended approach because it allows the new application to inherit the default application handlerURL of "/Shibboleth.sso" and greatly limits the amount of additional configuration work. It's also more secure.

...