For a Shibboleth Identity Provider to join one of the Tuakiri Federations (Test/Dev or Production), the following steps have to be done:
There are two federations available, both fully operational:
We recommend first registering a Test system into Tuakiri-TEST and after successful testing, register a production-ready system into Tuakiri Production.
Metadata distribution point
Metadata signing certificate
Federation Registry URL
Discovery Service / WAYF URL
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.
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 Appendix B - Tuakiri-TEST Federation 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:
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.
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.
This section gives the variants of the commands to be used when configuring the IdP to join the Tuakiri-TEST Federation (instead of Tuakiri Production).
To download the Tuakiri-TEST metadata signing certificate, run the following command:
wget https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-cert.pem -O $IDP_HOME/credentials/tuakiri-test-metadata-cert.pem
For loading the Tuakiri-TEST metadata, put the following into
<!-- Tuakiri-TEST --> <metadata:MetadataProvider id="Tuakiri-TEST" xsi:type="metadata:ResourceBackedMetadataProvider"> <metadata:MetadataFilter xsi:type="metadata:ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata"> <metadata:MetadataFilter xsi:type="metadata:SignatureValidation" xmlns="urn:mace:shibboleth:2.0:metadata" trustEngineRef="shibboleth.MetadataTrustEngine" requireSignedMetadata="true" /> </metadata:MetadataFilter> <metadata:MetadataResource xsi:type="resource:FileBackedHttpResource" url="https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-signed.xml" file="/opt/shibboleth-idp/metadata/tuakiri-test-metadata.xml" /> </metadata:MetadataProvider>
And the code to load the Tuakiri-TEST metadata signing certificate would be - also in
relying-party.xml in the
<security:Credential id="Tuakiri-Test-FederationCredentials" xsi:type="security:X509Filesystem"> <security:Certificate>/opt/shibboleth-idp/credentials/tuakiri-test-metadata-cert.pem</security:Certificate> </security:Credential>
The snippet to load attribute filter configuration would be (again, drop the srv namespace prefix with Shibboleth IdP 2.1.x):
<srv:ConfigurationResource xsi:type="resource:FileBackedHttpResource" url="https://directory.test.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml" file="/opt/shibboleth-idp/conf/tuakiri-test-attribute-filter.xml" />