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.
Federation Details
Federation name | Tuakiri Production | Tuakiri TEST |
---|---|---|
Metadata name |
|
|
Metadata distribution point | https://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-signed.xml | https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-signed.xml |
Metadata signing certificate | https://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-cert.pem | https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-cert.pem |
Federation Registry URL | ||
Discovery Service / WAYF URL |
Registering an IdP into the Federation Registry
Go to the respecting Federation Registry URL and:
- Register an Organisationfor your institution (if not already registered)
- For Contact Details, do not use a shared mailbox, alias or mailing list when entering an email address because the confirmation email contains a single-use link and may cause some confusion should more than one person attempt to use it
- For Organization Name, enter your DNS domain name.
- For Organization Display Name, enter your actual organization name.
- Wait for the Organisation to be approved
- Register your IdP under that Organisation
- Provide the Contact Details for the IdP admin (again, do not use a shared mailbox)
- Select the organisation and provide a name and description for your IdP
- Enter the base URL for your IdP (
https://idp.example.org
) - Enter the PEM encoded certificate used by your IdP for signing Shibboleth assertions (the default is
$IDP_HOME/credentials/idp.pem
). - Select the attributes the IdP will be able to release to the federation
- Select supported NameID formats. By default,
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
is already selected. If supporting SAML1, select alsourn:mace:shibboleth:1.0:nameIdentifier
. - Submit the details and wait for your IdP to be approved.
After having your IdP registration approved, click on the link sent to you to become an Administrator of the IdP's registration.
Confirmation email
- It is important to click on the link in the confirmation email, as this makes the recipient of the email an administrator of the Identity Provider being registered in the Tuakiri Federation Registry.
- The link in the confirmation email can only be used once.
- Same applies for the link sent for the Organization registration.
- It is important to click on the link in the confirmation email, as this makes the recipient of the email an administrator of the Identity Provider being registered in the Tuakiri Federation Registry.
- If supporting SAML1, define the SAML1 endpoints for your IdP.
ECP support
If supporting ECP, advertise also your ECP SSO EndPoint: in the Federation Registry registrtion for your IdP:
- Add a new "Single Sin On Service" Endpoint
- Select Binding:
urn:oasis:names:tc:SAML:2.0:bindings:SOAP
- Enter Location:
https://idp.example.org/idp/profile/SAML2/SOAP/ECP
(substituting your IdP hostname)
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 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 $IDP_HOME
Download the metadata signing certificate into
$IDP_HOME/credentials
:wget http://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-cert.pem -O $IDP_HOME/credentials/tuakiri-metadata-cert.pem
- In
$IDP_HOME/conf/relying-party.xml
Add the following snippet into the
ChainingMetadataProvider
:<!-- Tuakiri --> <metadata:MetadataProvider id="Tuakiri" 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="http://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-signed.xml" file="/opt/shibboleth-idp/metadata/tuakiri-metadata.xml" /> </metadata:MetadataProvider>
And add the following snippet into the
<security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
element:<security:Credential id="Tuakiri-FederationCredentials" xsi:type="security:X509Filesystem"> <security:Certificate>/opt/shibboleth-idp/credentials/tuakiri-metadata-cert.pem</security:Certificate> </security:Credential>
Remember to uncomment the
<security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
element if it is still commented out (it is commented out in the default configuration).
Configure attribute release/filtering through the federation:
- Contact the federation administratorsand request a URL for the Attribute Filter for your IdP.
- In the request, please include:
- The name (hostname or entityID) of your IdP
- An email address that should receive notifications whenever the attribute filter changes (these are notifications only, no action will be required).
- The attribute filter may have to be manually added to the list of attribute filters published. Once created, the URL will have the form of:
http://directory.tuakiri.ac.nz/attribute-filter/
<institution-domain>.xml
- In the request, please include:
Add the following entry into
<srv:Service id="shibboleth.AttributeFilterEngine"
in$IDP_HOME/conf/service.xml
(note that the URL varies for each IdP and has to be obtained from the federation administrators):<srv:ConfigurationResource xsi:type="resource:FileBackedHttpResource" url="http://directory.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml" file="/opt/shibboleth-idp/conf/tuakiri-attribute-filter.xml" />
Note: if your
$IDP_HOME
is different from/opt/shibboleth-idp
, change the file path in the above snippet accordingly.If configuring this in Shibboleth IdP 2.1.x, do not use the srv: namespace prefix - i.e., use just:
<ConfigurationResource xsi:type="resource:FileBackedHttpResource" url="http://directory.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml" file="/opt/shibboleth-idp/conf/tuakiri-attribute-filter.xml" />
We also strongly recommend you configure your IdP to periodically reload this file - we recommend at 2 hour interval. This is documented in detail in the IdP Install Manual: Reloading configuration section and Load AAF Atribute Filter sections. The simple step is to add the
configurationResourcePollingFrequency="PT2H0M0.000S"
andconfigurationResourcePollingRetryAttempts="10"
attributes to the<srv:Service id="shibboleth.AttributeFilterEngine"
element.<srv:Service id="shibboleth.AttributeFilterEngine" + configurationResourcePollingFrequency="PT2H0M0.000S" configurationResourcePollingRetryAttempts="10" xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine">
Now your IdP should be able to access service provides within the Tuakiri (Test/Dev) federation.
Appendix A - Alternative implementation
See here: Fetching Metadata and Attribute Filter and caching them locally
Appendix B - Tuakiri-TEST Federation
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 http://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
relying-party.xml
:<!-- 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="http://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:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
element:<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 srvnamespace prefix with Shibboleth IdP 2.1.x):
<srv:ConfigurationResource xsi:type="resource:FileBackedHttpResource" url="http://directory.test.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml" file="/opt/shibboleth-idp/conf/tuakiri-test-attribute-filter.xml" />