The term is admittedly generic, but lacking a better one, a Shibboleth ServiceProvider deployment divides the web resources it protects into logical groupings/collections it calls "applications".

The best way to think of these applications is as the unit of session management in the SP. That is, a browser session with the SP is established to one and only one application. If a user browses to a resource that is mapped into a different application, then a new session will be initiated through the IdP.

Usually these applications are best divided up on the basis of virtual hosts, as this provides the only real separation of resources that web browsers will honor when processing cookies. However, the software can be configured to partition resources in a nearly arbitrary way, even down to the document level. The software doesn't promise that one application can't gain unintended access to another application's session, but there is increased assurance of this if the applications do not share space on a single virtual host.

The real purpose behind these divisions is to enable a unique set of configuration options for the different resources, such as session policy, error handling look and feel, and SAML processing configuration, such as MetaData (including which IdPs can be used), IdPDiscovery, attributes of interest, etc.

In the ShibbolethXml file, the top-level <Applications> element contains the settings that are used for any requests for the "default" application. This is the label applied to any resources that are not explicitly overridden as being part of a separate application by attaching an applicationId attribute with the application's short label in the RequestMap.

You then place an <Application> element inside the top-level default at the end, with an id attribute inside it containing the label you want to give it. You can then supply the usual set of configuration elements for any settings you want to override. Anything not overridden will generally be inherited from the default settings.