RequestMap

1 Overview
2 Reference
- 2.1 Attributes
  - 2.1.1 Content Specifiers
  - 2.1.2 Content Settings
- 2.2 Child Elements
  - 2.2.1 Access Control Elements
  - 2.2.2 Nested Content Specifiers
3 Example

Overview

The <RequestMap> element is the root of the XML-based RequestMapper configuration (see the general documentation on this plugin for context). The root element is a globally applicable container that can apply settings to all requests.

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.

Apart from establishing default settings, its purpose is to act as a container for the rules you specify regarding virtual host, path, and/or query string matching to apply settings. The tree structure of the XML essentially maps to the tree structure of the URL space of your web server.

For a broader picture of how this all works, see the request mapper HOWTO.

Reference

Attributes

Content Specifiers

The root element applies to all requests, so it has no special attributes that govern matching behavior in contrast to the various child elements that are used to match specific requests.

Content Settings

The element supports a large number of XML attributes corresponding to the content settings supported by the SP:

Child Elements

Access Control Elements

Nested Content Specifiers

The following elements are supported to narrow the matching process:

Name	Cardinality	Description

Name	Cardinality	Description
<Host>	0 or more	Matches requests via the exact hostname (and optionally port and scheme).
<HostRegex>	0 or more	Matches requests with a URL prefix matching a regular expression. The prefix contains everyting up until the slash following the hostname or port.

The matching process is peformed by examining <Host> elements in order, and then checking any <HostRegex> elements in order, in separate passes (see the HowTo).

Example

A somewhat non-trivial example shows a pair of virtual hosts with one bound to an <ApplicationOverride> called admin. The path "/secure" on the primary host is protected automatically, while the entire admin host is protected along with access control rule embedded in the 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>