UK federation Test SP
You can use the UK federation Test SP to help you configure a new IdP, or to troubleshoot an existing deployment.
There are several Session Initiator links on the main page of the Test SP, which will allow you to use different SAML protocols and bindings. After authenticating at your IdP, you will be redirected back to the Test SP's Attribute Viewer. The Attribute Viewer shows some information about the authentication method and the attributes your IdP has released.
If you follow the Show SAML assertions link at the foot of the Attribute Viewer, you will find the plaintext assertions that your IdP has sent to the SP.
Testing a new IdP
Please note: to use our Test SP, your IdP must either be registered in the UK federation or be imported into the UK federation via eduGAIN.
Further, you should not attempt to gain access to any production service until you have verified that your IdP is properly configured and releasing attributes correctly.
Typical SPs in the UK federation will use the SAML 2 POST profile, so you should first follow one of the Default flows on the Test SP page. If you are testing a hidden IdP, you will need to enable Debug mode for OpenAthens Wayfinder and then use the DS flow with the OpenAthens Wayfinder Discovery Service to be able to locate your IdP. When you have selected your IdP, you will be redirected to your IdP to authenticate, and from there back to the SP. First check that you are being authenticated, then check that your IdP is releasing the attributes you expect. Alternatively, you could create a WAYFLess URL for your hidden IdP.
Some SPs use the legacy SAML 1 protocol. To test your IdP's SAML 1 operation, follow the UK Federation WAYF (always SAML 1.1) link. SAML 1 uses a two-step approach to attribute release, which requires the SP to make an Attribute Query to the backchannel (port 8443) of your IdP.
Access problems to SAML 1 SPs are often due to a failure of the backchannel Attribute Query. In this case, Show SAML assertions should display two assertions – one for the authentication, one for the attributes. If you fail to get any attributes but have a valid authentication, check your backchannel port is open and configured with the appropriate key/certificate.
Shibboleth IdPs
If you are testing a Shibboleth IdP, and you have trouble authenticating or releasing attributes, then ensure your log levels are turned up to DEBUG before re-testing, and check the logs; the idp-process.log is generally the most informative. If nothing is being written to the Shibboleth logs then check the webserver (Tomcat or Jetty) logs; it is advisable to keep checking the webserver logs anyway during the earlier stages of the installation.
The Shibboleth IdP also ships with the AACLI tool which can be used for testing your IdP locally. Running %{idp.home}/bin/aacli.sh -h will give some help text for the AACLI tool.