For a Shibboleth Identity Provider to join one of the Tuakiri Federations (Test/Dev or Pilot/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 will be two federations available:
- Tuakiri TEST/Dev (work in progress)
- Tuakiri Prod/Pilot (release date TBA)
Federation Details
Federation name |
Tuakiri |
Tuakiri TEST |
---|---|---|
Metadata name |
|
|
Metadata distribution point |
https://directory.tuakiri.ac.nz/metadata/metadata-tuakiri-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 Organisation for your institution (if not already registered)
- Wait for the Organisation to be approved
- Register your IdP under that Organisation
- Provide the Contact Details for the IdP admin
- 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.
Configuring your IdP to load the federation metadata:
The code snippets in this section have values for Tuakiri TEST/DEV federation. Please update them accordingly as per the table above - which boils down to removing the "test" component from the file names / URLs in all of the cases.
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.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-cert.pem -O $IDP_HOME/credentials/tuakiri-test-metadata-cert.pem
- In
$IDP_HOME/conf/relying-party.xml
- Add the following snippet into the
ChainingMetadataProvider
:<!-- Tuakiri Test --> <metadata:MetadataProvider id="Tuakiri-TEST" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" metadataURL="http://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-signed.xml" backingFile="/usr/local/shibboleth-idp/metadata/tuakiri-test-metadata.xml"> <metadata:MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata"> <metadata:MetadataFilter xsi:type="SignatureValidation" xmlns="urn:mace:shibboleth:2.0:metadata" trustEngineRef="shibboleth.MetadataTrustEngine" requireSignedMetadata="true" /> </metadata:MetadataFilter> </metadata:MetadataProvider>
- And add the following snippet into the
<security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
element:<security:Credential id="Tuakiri-Test-FederationCredentials-" xsi:type="security:X509Filesystem"> <security:Certificate>/usr/local/shibboleth-idp/credentials/tuakiri-test-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).
- Add the following snippet into the
- Configure attribute release/filtering through the federation:
- Contact the federation administrators and request a URL for the Attribute Filter for your IdP. The attribute filter may have to be manually added to the list of attribute filters published. The URL would look like:
http://directory.test.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml
- 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.test.tuakiri.ac.nz/attribute-filter/<institution-domain>.xml" file="/opt/shibboleth-idp/conf/tuakiri-test-attribute-filter.xml" />
Note: if your
$IDP_HOME
is different from/opt/shibboleth-idp
, change the file path in the above snippet accordingly.
- Contact the federation administrators and request a URL for the Attribute Filter for your IdP. The attribute filter may have to be manually added to the list of attribute filters published. The URL would look like:
- 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.