Shibboleth Service Provider Deployment

This page provides information on how to install, configure and operate a Shibboleth Service Provider to protect web services operated in the AAI.

Supported Platforms

SP Components and Environment

The Shibboleth Service Provider consists of a daemon shibd running on all major operating systems and a web server module mod_shib which is natively supported by:

  • Apache web server
  • IIS web server provided with the supported Windows versions

The Service Provider can protect any web server content by enforcing user authentication with AAI. Shibboleth can protect access to files, directories or locations with simple access control rules in Apache, IIS or other web servers.

Once a user was successfully authenticated all his user attributes are accessible via the web server environment. Therefore, all web applications (PHP, Perl, .Net, ASP, CGI, ...) running inside the web server can also use these attributes. Attributes are just read from the webserver environment, e.g. with $_SERVER['mail'] in PHP.

In order to protect Java applications, the servlet container like Tomcat must be operated behind a front-end Apache or IIS web server as shown in the figure above: Checkout the Java HowTo Page in the Shibboleth Wiki.

Note regarding Shibboleth SP 3  
  • Shibboleth SP 3.4.1 was released on 10. January 2023.
  • 03. November 2022: Shibboleth SP Guides updated for SP 3.4.
  • Check your existing configuration, update it to get rid of deprecation warnings for legacy elements.

Deployment Guides

  • If you are an experienced Shibboleth user and want to upgrade the configuration of an existing installation, you might also have a look at:
Access Control with Shibboleth
  • Once the Service Provider is deployed, it can protect any web resource on that web server, either with web server access rules or by providing the application authorisation information in form of user attributes.
Replace Targeted ID by Persistent ID
  • The attribute specification for eduPersonTargetedID is now marked as deprecated. The Shibboleth software originally introduced this attribute since the SAML1 standard was lacking support for a persistent identifier. Later, the SAML2 standard defined SAML NameID format persistent as method to transfer persistent identifier values compatible with eduPersonTargetedID. Since many more SAML implementations support SAML NameID format persistent than Targeted ID, it makes sense to finally migrate to the SAML2 standard way.
Enable an SP for Single Logout with the Switch edu-ID IdP
  • If many of your users login via the Switch edu-ID IdP, learn how your SP could support proper Single Logout (SLO) for this user base. Study the guide and adapt the configuration for your SP to support Single Logout.
Discovery Service Options for the Switch edu-ID Federation
Interfederation Support

Certificate Acceptance & Roll-Over

Design Templates

Other Relevant Information

  • How to skip the WAYF and provide direct login via a specific Home Organization:
  • With the Switch edu-ID Link Composer a Service Provider administrator can easily construct links for various flows and features useful for a service protected by Switch edu-ID.