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:
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:
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.
onfor resources that you want to always be protected.
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:
Native is specified, the XML-based access control rules placed in a
Native request map may be supplemented and overridden by access controls within the webserver itself, e.g.
.htaccess files. For
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.
<AccessControl> <Rule require="attributeName">requiredValue</Rule> </AccessControl>
NOT may be used to encapsulate
<Rule/> elements for negative and composite rules.
For example, the following request map would allow users with a
cryogenics who have a
2 and 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.
<RequestMapper type="XML"> <RequestMap applicationId="default" <Host name="www.supervillain.edu" scheme="https"> <Path name="deepfreeze" authType="shibboleth" requireSession="true"> <AccessControl> <AND> <Rule require="department">cryogenics</Rule> <Rule require="securityClearance">2</Rule> <NOT> <Rule require="affiliation">student</Rule> </NOT> </AND> </AccessControl> </Path> </Host> </RequestMap> </RequestMapper>