Page Comparison

Protect Content with Shibboleth

...

There are

...

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>

...

...

two ways that you can use the SP to protect content:

• Actively, by intercepting requests for particular resources and ensuring that a valid, authenticated session exists between the user agent and the SP software before passing along the request

• Passively, by publishing information about valid, authenticated sessions through CGI, but passing unauthenticated requests through unmolested

In both cases, the information about the session supplied by the SP is provided uniformly so that applications can be programmed to respond dynamically based on the information. The NativeSPAttributeAccess topic describes this mechanism in detail.

Active Protection

In the "active" mode, static web pages can be protected, and dynamic applications can be written to assume that authentication is done before they execute. It's also possible to apply static access control rules that restrict access based on the information associated with a session.

To impose active session requirements, you need to attach either the requireSession or requireSessionWith content settings to the resource. Mechanisms for doing this include native configuration approaches (Apache, Sun/iPlanet) and a generic configuration mechanism.

Passive Protection

In the "passive", or lazy session mode, the same set of resources can be exposed to both authenticated and unauthenticated access at the same time. This is obviously incompatible with both static resources (which would be left exposed, making authentication moot) and static access control (which would deny unauthenticated access). Thus, it's useful for dynamic applications that typically want to offer a "guest" mode by default, and initiate a user login only when desired or chosen by the user.

When using passive protection, you do NOT apply the requireSession content settings to the resource, but merely ensure that the SP software is active for the request (or often simply for the entire virtual host). For details, refer to the appropriate web server configuration topic (Apache, IIS, Sun/iPlanet, FastCGI).

To determine whether a session exists with your application, you can check for the presence of one of the "fixed" CGI variables or headers, such as "Shib-Identity-Provider"/"HTTP_SHIB_IDENTITY_PROVIDER".

If you want the user to login and begin a session, your application must issue an HTTP redirect to the location of a SessionInitiator handler using parameters described here.