For a Shibboleth Identity Provider to join one of the Tuakiri Federations (Test/Dev or Production), the following steps have to be done:
- Registering the IdP in the Federation Registry
- Configuring the IdP to load the federation metadata
- Configuring the IdP to release the attributes required by the federation.
There are two federations available, both fully operational:
- Tuakiri Test/Development Environment (Tuakiri-TEST) for testing deployments and developing new features
- Tuakiri Production Federation Service (Tuakiri) for ready-for-production Identity Providers and services.
We recommend first registering a Test system into Tuakiri-TEST and after successful testing, register a production-ready system into Tuakiri Production.
|Table of Contents|
Metadata distribution point
Metadata signing certificate
Federation Registry URL
Discovery Service / WAYF URL
Registering an IdP into the Federation Registry
Go to the respecting Federation Registry URL and:
If supporting ECP, advertise also your ECP SSO EndPoint:
In the Federation Registry registration for your IdP:
The IdP also needs to be configured to support ECP.
Configuring your IdP to load the federation metadata
The code snippets in this section have values for Tuakiri Production federation. Please update them accordingly as per the table above if configuring your IdP to join the Tuakiri TEST/DEV federation. (The key code snippets are for convenience given in the "Tuakiri-TEST specific" box below).
NOTE: Check what your IdP home directory is: the directory is typically called
shibboleth-idp - and on Debian and Ubuntu systems, it's commonly
/usr/local/shibboleth-idp, while on RedHat and CentOS it's
/opt/shibboleth-idp. The snippets below are referring to the IdP home directory as
To configure a 3.x IdP to Load the Tuakiri metadata:
For archival purposes, we also keep the original instructions for configuring the Tuakiri metadata into a 2.x IdP - unfold the box below to see the IdP 2.x compatible syntax:
Configure attribute release/filtering through the federation
To configure a 3.x IdP to Load the Tuakiri-managed attribute filter:
For archival purposes, we also keep the original instructions for configuring the Tuakiri-managed attribute filter into a 2.x IdP - unfold the box below to see the IdP 2.x compatible syntax:
Now your IdP should be able to access service providers within the Tuakiri federation.
Appendix A - Alternative implementation
Loading the metadata and the attribute filter files from a remote URL makes the IdP depend on the accessibility of the remote URL. While for metadata itself, the IdP software should be sufficiently resilient, for attribute filter configuration, this is not the case. Tuakiri will be running their servers serving these XML files according to best practices. However, some sites may prefer not to take on the risk and put the XML file loading outside of the IdP, into a separate process. This section describes this alternative implementation. This implementation first downloads the XML file into a temporary file on the local machine. Once this is completed it then replaces the original configuration file with the new one, and this will be detected by the IdP and will cause a reload of this file.