Child pages
  • Configuring a Shibboleth Identity Provider to join the Tuakiri Federation
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

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 also urn: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).

  • 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.

  • 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" and configurationResourcePollingRetryAttempts="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.

  • No labels