Page tree

The Shibboleth 2.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP30 and SP3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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.

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:

  • The main <Host> element's name should be changed to match the externally visible name for your machine.
  • The <Path> elements should be modified to match the externally visible directory structure you'd like to protect.
  • ShibRequireSession should be marked as on for 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. .htaccess or the application 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.

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

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 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>

Advanced Configuration

  • No labels