Versions Compared

Key

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

...

The Windows installer contains a fourth version field that indicates the patch level within a particular SP release. Initially 0, it will be incremented if patches to software included with but not part of the SP need to be updated (e.g., OpenSSL). Subsequent patch level installers will safely upgrade older versions and the ReleaseNotes will always document exactly what library versions are included in each release.

Note

Restricting ACLs

Note that prior to V3.4.1, the installer did not adjust file system ACLs based on your install path. As of that version, we have added changes that are designed to provide full access to the administrative/system accounts and read access to the standard “Users” group.

Wherever you choose to install the software, you should consider reviewing and hardening the file and folder access to that location. Most of these folders and files should be read only. The daemon process runs by default as a system account and should already have the necessary access. You should if possible prevent all other access to the private key file(s) as those need not be readable by anything else, and you need not allow any writing of files, or creation of folders or files by any other users.

If you run your web server under a different user account (not a member of the Administrators or Users groups) you will need to adjust the rights if you limit read access, but the web server should not in general require any write access whatsoever to those folders or files, as in-process logging is now routed to the Event Log by default.

This can be achieved at install time by specifying the account (our group) on the command line setting the WEBSERVER_USER property on the command line (see below)

Upgrades

Upgrading to new releases is handled automatically when the MSI installer is used. The system prevents configuration files from being overwritten and skips "initial install" tasks like generating keys. The Shibboleth daemon is restarted by the package but you will need to restart the web server you're using yourself.

Web Server Overview

...

New Installations place a restrictive file security ACL on the configuration directory. If you run your web server under a different user account (not a member of the Administrators group) you will need to adjust this ACL.

Installation with IIS

The plugin modules in support of IIS are always installed. If IIS itself is installed you will be prompted "Configure IIS7 module?".  Check this box to actually configure Shibboleth to run with IIS, in practice this can be done with two command.

...

Property

Description

KEYGEN_EXTRAS

Allows extra parameters to be passed to the keygen command used during installation. For instance,

Code Block
msiexec /i shibboleth-sp-3.0.0-win64.msi KEYGEN_EXTRAS="-h newSP.department.univerity.edu"

allows the addition of a subjectAltName in the generated certificate.

ALWAYS_START_SERVICE

Set this to FALSE to prevent the installer from starting the shibd service. This can be useful to debug installations (see below).

WEBSERVER_USER 3.4.1

The name of a User or User group to be granted explicit read access to the installation tree. Use this if your web server runs under a restricted account.

Shibboleth Service

Once installation is complete, you'll need to run the Shibboleth daemon, shibd, at all times that the SP is in use. shibd is a console application that is usually installed as a Windows service.

...