Native SP Request Mapping
The native SP matches incoming requests to its internal
<RequestMap> configuration and Shibboleth-related configuration of the web server to determine how to handle them. This matching is done on a literal string basis, making proper and consistent configuration of the request map and the web server itself critical.
The request map itself is a series of host and path elements that define how Shibboleth interacts with sequentially smaller pieces of the webspace served by this webserver. The most precise match is always used, allowing inner elements to selectively override broad outer rules.
The request map and associated webserver directives are only directly responsible for a limited portion of SP functionality:
- which application to associate with an incoming request, which in turn specifies most of the SP's behavior;
- whether a Shibboleth session must be established prior to any access of a resource;
- whether to export the assertions received in a transaction directly into the surrounding environment;
- and optionally access control rules to be applied to the request itself.
The configuration of request handling functionality is divided between the webserver configuration and Shibboleth's configuration. It's important to ensure that a couple things are configured for proper protection of a standard resource using Shibboleth attributes enforced by Shibboleth or the web server itself:
- The main
nameshould be changed to match the externally visible name for your machine.
<Path>elements should be modified to match the externally visible directory structure you'd like to protect.
- ShibRequireSession should be marked as
onfor resources that you want to always be protected.
- Proper access control rules need to be in place either within
shibboleth.xml, the web server's access control rules(e.g.
.htaccessor the application itself.
Two types of request mapper are supported by a stock installation of Shibboleth;
XML. The major difference is that XML-based access control rules placed in a
Native request map may be overridden by access controls within the webserver itself e.g.
XML request mapping, access control rules within the webserver itself will not be honored unless a special
<htaccess/> element is added to the map. This distinction is especially important for webservers hosting webspace for a variety of owners.
Access control rules making use of attributes and simple boolean logic can be placed into the request map by using an
<AccessControl> element within the path you want to protect. Each requirement is placed in a
<Rule/> element within
<AccessControl> by using the name or alias of an attribute resulting from the resolver.
NOT may be used to encapsulate
<Rule/> elements for negative and composite rules.
For example, the following request map would allow users with a
2 who aren't students to access
https://www.supervillain.edu/deepfreeze/. The default application will define the behavior of the provider. The rest of
https://www.supervillain.edu/ is unprotected by Shibboleth even if
.htaccess rules are specified.