The <RequestMapper> element configures the component used by the SP to map incoming requests to the set of configuration options that should be applied. You can think of it as a portable equivalent of the Apache <Location> feature, which associates Apache directives with specific URLs. Like that feature, the request mapper operates based on URL, not on the physical path of files.
Another critical role of the request mapper is to map each request to the appropriate Shibboleth application, thereby connecting the resource-oriented settings to the more general behavior defined per-application.
While Apache-based deployments can rely entirely on Apache functionality for this purpose, IIS provides no such capability. The request mapper allows the SP to insulate itself from the differences between servers.Another critical role of the request mapper is to map each request to the appropriate Shibboleth application, thereby connecting the resource-oriented settings to the more general behavior defined per-application
On Version 2.4 and above, omitting this element will result in a "Native" plugin with an empty/default configuration. This empty configuration maps all requests to default application settings and adds no other settings, unless overridden by web server-specific options.
Common Attributes
type(string)- Plugin type name.
...
For most deployments, this is the type to use. It is a hybrid that allows you to combine Apache commands in .htaccess files with XML-based configuration and seamlessly switch back and forth. The native commands override any XML-based attributes. For servers without native commands (IIS), this type is completely equivalent to the XML request mapper type below.
The Native request mapper's XML "portion" is a reloadable resource, which means that the XML content can be supplied inline, in a local file, or a remote file, and can be monitored for changes and reloaded on the fly. The root of the XML instance MUST be a <RequestMap> element.
...