Go to the respecting Federation Registry URL and:

• Register an Organisation for 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.
  • 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.

    Note
    title 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.

In the Federation Registry registration 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)

• Configure the IdP to load the Federation Metadata in /opt/shibboleth-idp/conf/metadata-providers.xml by adding the following snippet into the Chaining MetadataProvider.

  Code Block
  xml xml
  <MetadataProvider id="TuakiriMetadata" xsi:type="FileBackedHTTPMetadataProvider" refreshDelayFactor="0.125" maxRefreshDelay="PT2H" backingFile="%{idp.home}/metadata/tuakiri-metadata.xml" metadataURL="https://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-signed.xml"> <MetadataFilter xsi:type="SignatureValidation" certificateFile="${idp.home}/credentials/tuakiri-metadata-cert.pem" requireSignedRoot="false"> </MetadataFilter> <MetadataFilter xsi:type="EntityRoleWhiteList"> <RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataProvider>

   

  • Note: validity checking is implicitly turned on, so it is not needed to explicitly add the RequiredValidUntil metadata filter, which would only be useful to reject metadata published with a validity longer then maxValidityInterval milliseconds.  We recommend to rely on signature validation.  The Tuakiri metadata are being generated with a validity of one week.
  • Note: by default, metadata get refreshed only every 3 hours (0.75 factor out of 4 hours maximum refresh interval). 
    
    • To make metadata changes propagate faster (reload every 15 minutes), set the maximum refresh interval to 2 hours and the factor to 0.125 as above.
    • To avoid re-fetching the file even when not changed, turn on caching (memory caching is enough as we already do have a backing file)
  • See the IDP30 https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration and https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider documentation for more information.
  • Note: in IdP 3.0.0, the RetainedRole element was incorrectly using the namespace samlmd - as of 3.1.1, the namespace declared in metadata-providers.xml and used in the examples is md, consistent with other use.

• This definition is referring to a certificate used to verify the signature - store the certificate in /opt/shibboleth-idp/credentials

  No Format
  wget https://directory.tuakiri.ac.nz/metadata/tuakiri-metadata-cert.pem -O $IDP_HOME/credentials/tuakiri-metadata-cert.pem

  Note
  title Tuakiri-TEST specific
  When building a TEST IdP and registering into Tuakiri-TEST instead, please load instead the Tuakiri-TEST metadata with: Code Block xml xml <MetadataProvider id="TuakiriTESTMetadata" xsi:type="FileBackedHTTPMetadataProvider" refreshDelayFactor="0.125" maxRefreshDelay="PT2H" backingFile="%{idp.home}/metadata/tuakiri-test-metadata.xml" metadataURL="https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-signed.xml"> <MetadataFilter xsi:type="SignatureValidation" certificateFile="${idp.home}/credentials/tuakiri-test-metadata-cert.pem" requireSignedRoot="false"> </MetadataFilter> <MetadataFilter xsi:type="EntityRoleWhiteList"> <RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataProvider> and fetch the Tuakiri-TEST metadata signing certificate instead: No Format wget https://directory.test.tuakiri.ac.nz/metadata/tuakiri-test-metadata-cert.pem -O $IDP_HOME/credentials/tuakiri-test-metadata-cert.pem

• Edit $IDP_HOME/conf/services.xml and add the additional attribute filter as an additional resource in the shibboleth.AttributeFilterResources util:list bean, using the built-in FileBackedHTTPResource:

  Code Block
  language html/xml
  <bean id="TuakiriAttributeFilterResource" class="net.shibboleth.ext.spring.resource.FileBackedHTTPResource" c:client-ref="shibboleth.MemoryCachingHttpClient" c:url="https://directory.tuakiri.ac.nz/attribute-filter/institution.domain.ac.nz.xml" c:backingFile="%{idp.home}/conf/tuakiri-attribute-filter.xml"/>

• For Tuakiri-TEST, the configuration would be the same, just the URL would be different - please use the URL provided by the federation administrators.