Protect Content with Shibboleth

There are three main choices to protect content using information received by Shibboleth: the application can make decisions, the web container can make decisions, or SP can protect content itself using the XML request map.

By default, no login is required to access content. This is sometimes desirable for shared webspace where an authenticated user gets additional options. If you want to force the user to login before any access to a path, add ShibRequireSession on to an Apache <Location/> block, or for either IIS or Apache, add requireSession="true" to the RequestMap. See session initiation for details on how to customize how and when to ask a user to login.

If Apache is the web server, the Shibboleth module needs to always be able to hear requests. That's done by the minimal configuration for the Apache virtual host:

<Location /secret/>
    AuthType shibboleth
    require shibboleth
</Location>

A path of / can be used to allow Shibboleth to check out every request on the host.

Application Access Control

All the attributes that Shibboleth acquires in a trusted way can be supplied to the application to allow the application to make the access control decisions. This is the preferred approach, because the application can display the most helpful errors and refusals.

The attributes received are all made available as HTTP header/environment variables with an name that matches the id defined in attribute-map.xml. You can see a long list of defaults there, or create your own.

XML Access Control

shibboleth2.xml can use <RequestMapper type="XML"> with a set of <Host> and <Path> elements to represent part of your webspace. When a request comes in that matches the hosts and paths, a set of <Rule>s can be applied, optionally using boolean <AND>, <OR>, or <NOT> logic elements. For example:

<Host name="www.example.org" authType="shibboleth" requireSession="true">
    <Path name="treeHouse">
        <AccessControl>
            <OR>
                <Rule require="cn">Bob</Rule>
                <Rule require="cn">Steve</Rule>
                <Rule require="cn">Marlena</Rule>
            </OR>
        </AccessControl>
    </Path>
</Host>

<Host name="www.example.org" authType="shibboleth" requireSession="true">
    <Path name="topsecret">
        <AccessControl>
            <AND>
                <Rule require="employeeType">Staff</Rule>
                <OR>
                    <Rule require="ou">Marketing</Rule>
                    <Rule require="ou">Management</Rule>
                </OR>
                <NOT>
                    <Rule require="ou">Engineering</Rule>
                </NOT>
            </AND>
        </AccessControl>
    </Path>
</Host>

<Host name="www.example.org" authType="shibboleth" requireSession="true" />

<Host name="www.example.org" authType="shibboleth" requireSession="true">
    <Path name="private-stuff" />
</Host>

Apache-based access control

Apache can also be used to enforce access controls itself using httpd.conf or .htaccess files. This supports regular expressions and can be managed easily in a distributed fashion.

<Location /notverysecure/>
   AuthType shibboleth
   ShibRequireSession On
   require valid-user
</Location>

<Location /orgpeople/>
   AuthType shibboleth
   ShibRequireSession On
   require mail ~ ^.*@.*.org$
</Location>