Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This document describes the procedure used to install Shibboleth Service Provider (SP) software on Centos, RedHat and to configure it to work with the Cornell Shibboleth Identity Provider (IdP).

If you are moving shib protected domain to a new serve, please use instruction here: Move Shibboleth Service Provider to a Different Server

Prerequisites

  • Apache must be installed and your website have an SSL certificate installed and SSL enabled. To request a SSL certificate: https://it.cornell.edu/ssl/renew-or-request-ssl-certificate.
  • Shibboleth doesn't support http access. If http access is supported on your site, define a redirect rule in Apache configuration that route http traffic to https.
  • Make sure your server time is accurate.
  • Your server has user shibd available.
  • We do not recommend the use of the old prefork MPM and strongly encourage the worker MPM. The prefork option will fail under load in a variety of cases, with some limited workarounds possible.

...

Expand
titleUpdate shibboleth2.xml

Download our sample shibboleth2.xml and replace your /etc/shibboleth/shibboleth2.xml with downloaded file. Open shibboleth2.xml in a text editor.

  • Update SP entityID:

 Search <ApplicationDefaults entityID="https://mysite.cit.cornell.edu/shibboleth"... >.  EntityID is the  Unique identifier for your SP. Cornell Shibboleth Identity Provider(IDP) provides service to many applications. This entityID will help Cornell IDP to identify your SP. We recommend you follow shibboleth convention named it "https://xxx/shibboleth". It's better not include space or special characters in it( / and : are fine). One SP can server multiple sites in your Apache so it does not necessarily equate to the hostname(s) at which your service runs. 

  • Update SP session:
    Search <Sessions lifetime="28800" timeout="3600" ...>

--- lifetime is the maximum duration in seconds that a session maintained by the SP will be valid.The settings shown in the example will set your Shibboleth session lifetime to 28800 (8 hours). The maximum session lifetime you can set is 36000 (10 hours).

--- timeout is the maximum inactivity allowed between requests in a session maintained by the SP. The settings shown in the example will set your Shibboleth session timeout to 3600 (1 hour).


Info
titleForce authentication

When session expire or timeout, user will be redirected back to Identity Provider(IDP). If user still has active IDP session, user will NOT be prompted for login screen. They will just be redirected back to your website. If you would like to force user re-login when SP session expire/timeout, please configure Force Re-Authentication in SP:Configure a Service Provider to Force Re-Authentication

 --- postData="ss:mem" postTemplate="postTemplate.html" postLimit="1048576"

Add it to <Sessions ..> if your website hosts web form(with Content-Type application/x-www-form-urlencoded). Web form POST data with Content-Type application/x-www-form-urlencoded will be saved in the Shibboleth memory cache rather than discarded when a user requires authentication after filling out a web form. "postTemplate.html" is located in /etc/shibboleth directory. Modify it to meet your website's style. "postLimit" is the maximum number of bytes to allow when saving off POST data. Over this limit, a warning in the log will appear, but the data will not be saved. When not defined it uses the default which is 1048576 bytes(1024k).

More information: https://wiki.shibboleth.net/confluence/display/SP3/Sessions

  • Update the support contact: 

Search < Errors supportContact ="root@localhost"  helpLocation ="/about.html" styleSheet ="/shibboleth-sp/main.css"  /> . Change the email address to your application's support email address. Change the helpLocation to your application's help page.

  • Update redirectLimit if needed


Expand
titleCreate signing and encryption key

If Shibboleth is installed via RPM, signing/encryption key and certificate files are generated automatically. Check if you have sp-signing-cert.pem, sp-signing-key.pem, sp-encrypt-key.pem, sp-encrypt-cert.pem in /etc/shibboleth directory. If they are not there, generate them.

./keygen -u shibd -g shibd -n sp-signing -h yourServername -y 10 (your servername will be the CN of the certificate) 
./keygen -u shibd -g shibd -n sp-encrypt -h yourServername -y 10

After you run the commands, four files are created: sp-encrypt-cert.pem, sp-encrypt-key.pem, sp-signing-cert.pem, sp-signing-key.pem. These files should be owned by shibd.

NOTE: Signing and encryption certificates are included in your SP's metadata. You should preserve these four files and put them back when you do a fresh SP rebuild using Docker or other container software.

...