This guide describes the installation and configuration of a
Shibboleth Sevice Provider (SP)
2.4.3 on a Solaris from sources system.
It covers the installation of the Shibboleth web server module as
well as the Shibboleth daemon and their configuration for the SWITCHaai or AAI Test
For further information about the Shibboleth Sevice Provider, please have a
look at the references.
Please ensure that the following prerequisites are met before proceeding
with the installation of the Shibboleth Service Provider:
A valid certificate is required for decrypting SAML assertions and/or
establishing SSL connections to Identity Providers.
Please refer to
http://www.switch.ch/aai/certificates/ for further information about
certificates and certificate requirements.
The same certificate can be used by the web server and by the Shibboleth
Service Provider. However, it is recommended that Shibboleth uses a self-signed certificate whereas the web server should use a certificate from a well-known CA.
Please follow the steps described below to create a self-signed certificate for between the Shibboleth components.
SWITCHaai Certificate Acceptance Policy.
The following issues are known and should be taken into account when
installing a Shibboleth Service Provider:
libcurl SSL/TLS support
The Shibboleth Service Provider requires that the libcurl library is
linked against openssl and not gnutls.
1. Setup Profile
In order make configuration easier and more convenient we kindly ask you to
provide some information about your environment. This allows aut-generating
and custom-tailoring some of the configuration files.
1.1 Quick download of configuration files
If you are in a hurry and know the whole setup process, you can download
all relevant configuration files directly here:
According to the convention, the entityID should have the form of a URL. If the entityID is used as a URL (https://sp.example.org/shibboleth), this URL should return an entity's metadata. In order for this to work, the web server must be configured accordingly.
Create a new configuration file, e.g. /etc/apache2/sites-available/sp.example.org, or modify an existing one like default-ssl :
Use the status URL https://sp.example.org/Shibboleth.sso/Metadata for a quick test. This URL should return the dynamically generated XML metadata of this Service Provider.
AAI Resource Registry
In order to activate the Service Provider within the federation it is necessary to register it with the Resource Registry. After this procedure, the metadata of this Service Provider will be included in the federation metadata. Therefore, all AAI components will learn about this new Service Provider.
The purpose of the Resource Registry is to have an up-to date list of all Identity Providers and Service Providers in the SWITCHaai Federation.
(See the information about the Resource Registry) in order to generate federation metadata and various configuration files.
Log in with a SWITCHaai or AAI Test account. Use organisation account to get access. In case your organisation doesn't operate yet an AAI Identity Provider,
please ask email@example.com for an account.
SWITCHaai accounts can also be used to manage AAI Test resources but not vice versa.
Click on the tab Resources
Click on Add a Resource Description
Click on Run Shibboleth 2.x wizard
Fill out all forms that are marked incomplete. Some forms do not need to be filled out completely.
After completing all sections (they should all be marked as 'optional' or 'ok'),
click on Submit for Approval.
A Resource Registration Authority administrator of your organization then has to approve the Resource Description in order to make it active. Only after this step, its description will be included in federation metadata.
Simple Test Resource
For a real test that shows if the Service Provider retrieves any user attributes
from an Identity Provider,
you must first protect a resource,
This can be accomplished by adding
the following directives to the Apache site configuration,
After restarting Apache, try to access: https://sp.example.org/secure/. This directory is protected by Shibboleth in the default configuration. Even if the directory does not exist. When accessing this URL the authentication should
be initiated and one should be redirected either to the WAYF
or to an Identity Provider.
Upon successful authentication, a HTTP 404 error
(File not found) might be returned, because there might be no directory /secure in the web server root directory.
Anyway, if you can access
and get back information about the session like the issuer (IdP) and released
attributes, this is a good test that the Service Provider was set up successfully.
If more testing is needed, e.g. to get the values of the released attributes, add a simple PHP script into the secure/ directory, like that index.php:
This PHP script has to be placed in a Shibboleth protected directory (e.g. /secure from above).
If successfully authenticated and authorized, you should see some environment variables that contain your user attributes.
If some of the above tests are unsuccessful, we recommend the following procedure:
Have a look at the logfiles. They can be found at the path set in the property log4j.appender.native_log.fileName
defined in /etc/shibboleth/native.logger and the path log4j.appender.shibd_log.fileName
/etc/shibboleth/shibd.logger for WARN and ERROR messages.
Most probably /var/log/shibboleth/native.log and /var/log/shibboleth/shibd.log.
Check /var/log/apache2/error.log and /var/log/apache2/access.log
Set the log level (log4j.rootCategory) of /etc/shibboleth/native.logger and
/etc/shibboleth/shibd.logger to DEBUG.
Once the problem is solved, don't forget to set it back to WARN or INFO to prevent your log files from growing too big.
6.2 Common problems
Find below a list of common problems and possible solutions:
No log files are written
Check the permissions of the log files or the path for the log files set in /etc/shibboleth/native.logger
or /etc/shibboleth/shibd.logger . If shibd is not run as root user, you might have to adapt the owner of the log directory and files to the user that runs shibd.
Some good practices according Service Provider productionalization:
BEST CURRENT PRACTICES for operating a SWITCHaai Service Provider
The document describes best current practices for operating a Service Provider (SP) within the SWITCHaai federation in production use. It is meant to cover service management and operational related aspects as well as the technical infrastructure for successfully operating an SP.