The <RequestMap> element is the root of the XML-based request mapper configuration.

<RequestMap applicationId="default">
    <Host name="www.example.org">
        <Path name="secure" authType="shibboleth" requireSession="true"/>
    </Host>
    <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true">
        <AccessControl>
            <Rule require="affiliation">faculty@osu.edu student@osu.edu</Rule>
        </AccessControl>
    </Host>
</RequestMap>

Attributes

Content Specifiers

The root element applies to all requests, so has no attributes to limit matching behavior.

Content Settings

XML attributes corresponding to request mapper properties are used.

A special requirement of this root element is that it MUST contain an applicationId attribute with a value of "default", which in turn matches the required id attribute of the outer-most <ApplicationDefaults> element in the shibboleth2.xml file.

Child Elements

Access Control

One of the following elements can be used to attach an access control policy to the resource. This is a violation of the axiom that the SP doesn't do access control, but it's really just a call-out that has some predefined plugins you can use as examples to create more.

<htaccess>
- Enables Apache .htaccess support during the authorization phase. This is automatic and implicit for the "Native" request mapper, but can be enabled by hand if the "XML" request mapper is used. Note that this will fail for non-Apache servers.

<AccessControlProvider>
- Attaches a custom access control policy supported by a plugin.

<AccessControl>
- Attaches an access control policy using the sample XML-based plugin provided with the SP. This is just a short-hand for embedding the policy in the element above, if you want the policy inside the same file.

If no element is included (or inherited or implicitly enabled), any access control is left to the resource.

If an error occurs when processing this element, a dummy policy to deny access is installed to prevent accidental exposure.

Nested Content Specifiers

Zero or more of these "overrides" to match specific virtual hosts can be included.

<Host>
- Matches requests with the exact hostname (and optionally port and scheme).

<HostRegex>
- Matches requests with a URL prefix matching a regular expression. The prefix contains everyting up until the slash following the hostname or port.

Matching is done by examining <Host> elements in order, and then checking any <HostRegex> elements in order.

For more details on how the request mapping process works, see the request mapper HOWTO.