NativeSPWindowsInstall

Windows Installation

The native Shibboleth SP is available for Windows with modules for all the supported web servers. There is an installer available that works fairly well most of the time.

It is recommended that you install the software to C:\opt\shibboleth-sp if possible. The installer may not default to this drive letter.

One thing the installer does not handle properly is a straight uninstall, which appears to hang. As a result, upgrades can't be done directly. Instead, you should remove the existing version by using the "Change" option in the Add/Remove Software list, and then select Remove from there. You should usually reboot at this point.

Once this is done, you can do a reinstall of the new version to the same directory without damaging any existing configuration files.

Install for IIS 5
Install for IIS 6
Install for IIS 7
Install for Apache

It's also possible (though not simple) to build the SP and its dependencies from source using Visual Studio 2005.

Build from Source

Shibboleth Service

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

To run the process in console mode for testing or to diagnose major problems, supply a -console parameter when running it.
If shibd won't start, use the -check option from the command line to echo most logging information to the console for debugging.

Other parameters can be used to install (or remove) shibd from the service database and subsequent control is generally via the Service Control Manager applet.

Monitoring the Service

Newer versions of Windows support automatic restart of failed services. We suggest using this feature to restart shibd when it fails. Although stability is good, maximum reliability will be achieved by monitoring the process.

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.