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:
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
<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
<NOT> logic elements. For example:
Apache-based access control
Apache can also be used to enforce access controls itself using
.htaccess files. This supports regular expressions and can be managed easily in a distributed fashion.