In Finnish

Installation options

To install the Shibboleth Service Provider server, you can use the sample role designed for the automation tool Ansible or do the installation manually, for example, according to the steps below. The Ansible role and the steps described below are examples of how to install the software. According to the service contract, the partner or member of the Haka network is responsible that the installation complies with the network's requirements and that the service is maintained in such a way that compliance with the requirements remains even after the initial installation.

You can find the ansible role at the following link: https://github.com/CSCfi/ansible-role-shibboleth-sp

Installation

This instruction goes through the installation of the Shibboleth SP software on the RedHat operating system using prepackaged installation packages. In most cases, each organization has its own distribution channel from which the software is installed. Please inquire about it from your own IT maintenance. The use of channels is desirable because then also the updating of the software can be handled automatically and in a controlled manner.

Shibboleth SP is installed on the side of the Apache HTTP server, for which the "mod_shib_22.so" module comes in the package. This module only works with Apache version 2.2. At the moment, when pre-packaged, you can only get a module that works in Apache version 2.2 up to RedHat 6, Apache version 2.4 and mod_shib_24.so are used from shutdown onwards.

Once the distribution channels are configured, you can move on to installing Shibboleth itself.

yum install shibboleth

Configuration

Once Shibboleth is installed, you can proceed to configuration. The configuration files can be found in a predictable location, the "/etc/shibboleth" directory.

shibboleth2.xml

The most essential part of the ApplicationDefault element is the value of the attribute entityID, this is the future entityID of Shibboleth SP, which will be used in many places in the future. Set the value to a value according to your environment. The Haka federation also requires the signing of Authentication requests, this is done by setting the value "front" or "true" to the "signing" attribute.

<ApplicationDefaults entityID="https://testsp.funet.fi/shibboleth" REMOTE_USER="eppn persistent-id targeted-id" signing="front" encryption="false">

The login source is configured in the SSO element. The login source can be a single IdP or the Discovery Service (formerly WAYF). The SSO element is therefore given either the entityID attribute in the case of a single IdP or the discoveryURL.

A single IdP
  
<SSO entityID="https://idp.csc.fi/idp/shibboleth"> SAML2 </SSO>
  
or the Haka-test federation's (test side) Discovery Service
  
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://testsp.funet.fi/shibboleth/WAYF"> SAML2 </SSO>
  
or Haka Federation's (production) Discovery Service
 
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://haka.funet.fi/shibboleth/WAYF"> SAML2 </SSO>

The Errors element contains the contact information that is given on the error page. This is good to fill out so that users know how to contact the right place. Unfortunately, this is often left unfilled and it is easy to contact the maintenance of either the federation or the IdP, although often the problem is with the local SP.

<Errors supportContact="haka@csc.fi" logoLocation="/shibboleth-sp/logo.jpg" styleSheet="/shibboleth-sp/main.css"/>

The MetadataProvider element is an integral part of Shibboleth SP's functionality, this element defines the sources of credit relationships, be they local metadata or external. It is essential that the signature is always checked, even if the metadata is retrieved behind SSL. In federations, the numbers of IdPs and SPs are alive and it is good to take care that the metadata is updated regularly (at least once a day). Metadata is also best before time and outdated metadata must not be used (validUntil), this is also why it is good to take care of automatic updating.

In the example below, the metadata of the Haka federation's production is fetched once an hour and the signature is checked with the haka-sign-v9.pem certificate. In addition to this, the example also shows how to limit the credit relationship to only one IdP using whitelisting. The example also checks that the metadata contains a validity period and also that this does not exceed 30 days, otherwise it is rejected. The time is given in seconds.

Haka-federation metadata (production)
  
<MetadataProvider type="XML" url="https://haka.funet.fi/metadata/haka-metadata-v9.xml" backingFilePath="haka-metadata.xml" reloadInterval="3600">
 <MetadataFilter type="Signature" certificate="/etc/pki/tls/certs/haka-sign-v9.pem"/>
 <MetadataFilter type="Include">
  <Include>https://idp.csc.fi/idp/shibboleth</Include>
 </MetadataFilter>
 <MetadataFilter type="RequireValidUntil" maxValidityInterval="2592000"/>
</MetadataProvider>
 
or Haka-test-federation (test)
  
<MetadataProvider type="XML" url="https://haka.funet.fi/metadata/haka_test_metadata_signed.xml" backingFilePath="haka_test_metadata_signed.xml" reloadInterval="3600">
 <MetadataFilter type="Signature" certificate="/etc/pki/tls/certs/haka_testi_2018_sha2.crt"/>
 <MetadataFilter type="Include">
  <Include>https://testidp.funet.fi/idp/shibboleth</Include>
 </MetadataFilter>
 <MetadataFilter type="RequireValidUntil" maxValidityInterval="2592000"/>
</MetadataProvider>

The CredentialResolver element defines key pairs that are used to sign messages sent to the IdP and to decrypt received messages. These keys must match the keys that you have also set in the metadata of the federations with which SP has a credit relationship.

<CredentialResolver type="File" key="/etc/pki/tls/private/testsp.funet.fi.pem" certificate="/etc/pki/tls/certs/testsp.funet.fi.crt"/>

  • No labels