NativeSPLinuxInstall

Linux Installation

Shibboleth can be built on most versions of 32- and 64-bit Linux, but is officially supported only on the following distributions at this time:

Red Hat Enterprise and CentOS 6, 7 (packages only provided for 7.4+)
SUSE Linux Enterprise Server 11-SP3, 11SP4, 12SP2, 12SP3

The official packages are built for, and integrate with, only the Apache (httpd) package that is supplied with the OS. When building from source or SRPM, you can accomodate any version of Apache (or its derivations) that is compatible, but we officially support only Apache installations built using the official Apache sources and for versions that are not EOL (end of life) by the ASF.

Information about Red Hat Enterprise 6+ and CentOS 6+

Information about SELinux

If your distribution supports the RPM package manager, it is strongly suggested that you install using RPMs built for your specific distribution, or by rebuilding the SRPM source packages provided. If this is not possible, you can build from source.

Under no circumstances should you attempt to install a set of RPM packages built for/with a different OS or version from your own. This will usually lead to unpredictable problems and support issues. Instead, just rebuild the SRPM packages and then you can install them anytime you need them.

Install from RPM
Build from SRPM
Build from Source

Upgrade using RPM

Initial Testing

You can test to ensure that the SP is running properly and the surrounding environment is correct by accessing https://localhost/Shibboleth.sso/Status from the actual web server machine. You MUST use "localhost" as the hostname or it WILL NOT WORK by default. If this test is successful, then the software is ready for further configuration.

You can also access the Status handler from other clients or using a non-localhost name, but only if you change the acl parameter in the configuration to permit your client address or remove it entirely to open up access to anybody. The ACL is present by default because the Status handler can return some arguably sensitive information about your configuration.

Now you can progress to the Getting Started material, or if you're in the very early stages of evaluation, try a more controlled scenario by using the TestShib IdP. (Note that before using the TestShib IdP, you'll need to complete the first step from Getting Started, setting the entityID attribute in the ApplicationDefaults element of shibboleth2.xml.)

Once you've actually configured the SP with its own settings and metadata from at least one IdP, in order to check that the SP is "working":

Protect a directory by requiring a Shibboleth session. Usually, this is already done by default for the location "/secure".
Next, you typically place a script inside the protected directory that dumps the web server environment. With PHP for example you could in the easiest case just place a script there with the following:
```
<?php print_r($_SERVER) ?>
```
A more advanced version of such a script can be found here.
Make sure that the Shibboleth-supplied variables are present. If there is a non-empty variable called Shib-Application-ID, you successfully authenticated and have a valid session. However, you also should check if there are other non-empty Shibboleth variables defined in the attribute-map.xml file. If there are no variables like mail or givenName or surname, the IdP either releaseed no attributes, or the attribute request failed (the latter usually only applies when using an older IdP). In this case, have a look at the shibd.log file.