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. Check the hostname, scheme, and other information and verify that the
shibd daemon can be contacted. If this test is successful, then your provider is ready for further configuration to interoperate with the world. Progress to testing your provider using the TestShib IdP or other testing facilities.
You can also access the Status handler from other clients, 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 potentially sensitive information about your configuration.
In order to check that the Service Provider receives any attributes you simply have to:
- Protect a directory with Shibboleth by requiring a Shibboleth session. Usually, this is already done per default for the directory /secure
- Next, you have to 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 code: here. A more advanced version of such a script can be found
- Make sure that the Shibboleth variables are present. If there is a non-empty variable called Shib-Application-ID, you successfully authenticated and have a valid Shibboleth 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 Identity Provider either didn't release any attributes for you or the attribute request failed (the latter usually only applies when using an older IdP). In this case, have a look at the