Starting the Shibboleth Service
To get Shibboleth running and verify your installation, you first need to start the "Shibboleth Daemon" service (on Windows using the Service Control Manager, on Linux by starting the shibd daemon. If it fails to start properly, the most likely cause (assuming you rebooted) is a configuration file error. Assuming it does start successfully, a log file will be created (usually in var/log/shibboleth ) and will indicate whether any problems were detected. This log file is the most common place to look for error messages and research problems, so you'll want to become familiar with it.
You can also test your configuration from the command line by running c:\opt\shibboleth-sp\sbin\shibd -check on Windows or /sbin/shibd -t on Linux. This is useful if you make changes and want to test them before restarting the services.
Starting the Web Server
Once the Shibboleth module/filter is installed and configured, you should be able to start your web server normally. If it fails to start, the most likely reason is that the file permissions on the Shibboleth installation tree are too strict. The web server's user account needs read access to the Shibboleth files and write access to the logs. On Windows, an IIS web server using Shibboleth typically runs under a special anonymous access account because user authentication is handled by Shibboleth instead of Windows. Newer versions also enable applications to run in special "App Pool" processes, and the user account of this process may need similar access.
You should test things initially by accessing a default, unprotected page to make sure the server seems happy. If not, check the Apache error log or Windows event log for any signs of trouble. There might also be information in the module/filter log file if the failure comes late in the startup process.
Running a Real Test
For 2.0 testing information, see this wiki topic .
On earlier versions, by default (unless you've modified the example configuration), anything you place in /secure will be session-protected. When you access such a URL, your browser should be redirected to the location specified in shibboleth.xml in the wayfURL attribute. There can be multiple <SessionInitiator> elements, each with its own wayfURL , but one of them will be labeled as a default. This will typically be either the LSU login service or a directory listing of possible identity providers to select from, LSU among them. Once you've logged in with your own account, the browser should be directed to POST a form or redirected back to an assertion consumer service URL on your server, typically the location /Shibboleth.sso/SAML/POST , and then be redirected to the originally requested URL.
If this all happens, then at a minimum the authentication process was successful, and there may be user attributes present. A common test approach is to install a CGI script or program to display all of the environment variables, some of which should contain information provided by Shibboleth. If Perl is available on your server, you can use a simple script like printenv.pl to do this. On IIS, an ASP script like printenv.asp should work. Of course, you'll need to configure support for such scripts in the directory you test in. Information provided by Shibboleth will typically be in headers that are prefixed with HTTP_SHIB_
If things worked, congratulations, you should be in good shape to proceed. If not, the place to start looking for problems is the Shibboleth service log file.
