The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Protect Content with Shibboleth

There are other topics that detail how to configure the behavior of the SP when talking to IdP's; this just tells you how to control content once you receive an attribute.

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:

Allow a few specific users
<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>
Allow marketing and management staff, but not staff from engineering
<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>

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.

Let in anyone from an IdP I trust
<Location /notverysecure/>
   AuthType shibboleth
   ShibRequireSession On
   require valid-user 
</Location>
Anyone with a .org email by regex
<Location /orgpeople/>
   AuthType shibboleth
   ShibRequireSession On
   require mail ~ ^.*@.*.org$
</Location>
  • No labels