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:

Basic Configuration

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:

Two types of request mapper are supported by a stock installation of Shibboleth: Native and XML. When 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.

    <Rule require="attributeName">requiredValue</Rule>

The operators <AND>, <OR>, and NOT may be used to encapsulate <Rule/> elements for negative and composite rules.

For example, the following request map would allow users with a department of cryogenics who have a securityClearance of 2 and aren't students to access The default application will define the behavior of the provider. The rest of is unprotected by Shibboleth even if .htaccess rules are specified.

<RequestMapper type="XML">
    <RequestMap applicationId="default"
        <Host name="" scheme="https">
            <Path name="deepfreeze" authType="shibboleth" requireSession="true">
                    <Rule require="department">cryogenics</Rule>
                    <Rule require="securityClearance">2</Rule>
                        <Rule require="affiliation">student</Rule>

Advanced Configuration