Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Metadata configuration

Note

All examples below reference the eduID.at Metadata Signing Key in their configuration and will only work once the certificate has been copied to (by default) /etc/shibboleth. Do not skip this step!

...

Code Block
languagehtml/xml
titleAll IDPs registered with ACOnet plus Interfederation IDPs
<MetadataProvider type="XML" url="http://eduid.at/md/aconet-interfed.xml"
          validate="true" backingFilePath="aconet-metadata.xml" reloadInterval="14400">
    <MetadataFilter type="Signature" certificate="aconet-metadata-signing.crt"/>
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
    <MetadataFilter type="EntityRoleWhiteList">
        <RetainedRole>md:IDPSSODescriptor</RetainedRole>
        <RetainedRole>md:AttributeAuthorityDescriptor</RetainedRole>
    </MetadataFilter>
    <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
      attributeName="http://macedir.org/entity-category"
      attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      attributeValue="http://refeds.org/category/hide-from-discovery" />
</MetadataProvider>

Metadata filter examples

The Shibboleth SP software has powerful Metadata filtering capabilities which allow to restrict entities known to the SP via SAML metadata to only those matching certain criteria. Below are a couple of examples that are useful in specific situations. For convenience ("copy+paste") these are all self-contained but can be composed and arranged as specified in the documentation.

Campus-internal SPs (Whitelist)

Many institutions use Shibboleth and SAML also for internal "campus federation", i.e. with Service Providers not exposed to the eduID.at Federation but only known to the institutions' own IDP. (That IDP is usually the only IDP that knows about such "campus" SPs.) Still these SPs will need trustworthy and current SAML metadata for the institutional IDP. The easiest and most secure way to achieve that is by pointing such SPs to the eduID.at federation Metadata but also adding a metadata whitelist filter, which effectively removes all other IDPs. E.g. only limiting an SP to the Vienna University SAML IDPs (production and test instances):

...

Of course the eduID.at key for signature validation needs to be downloaded/configured on these SPs just like on any other (i.e., SPs that are registered with the eduID.at federation) even though the SP itself is not exposed to the federation. That also means the institutional IDP needs a way to register those SPs, but usually an XML file with SAML metadata managed directly at the IDP is sufficient for this.

Prevent all access from OpenIDP (Blacklist)

If deployers of a Service Provider are certain they don't have a current (or future) use for identities provided by the ACOnet OpenIDP they could filter it out at the metadata level, preventing any logins from that IDP wholesale:

...

Note that if you're using the Shibboleth EDS Discovery Service you could chose to only hide an entity in the discovery service, but keep it's metadata available to the Shibboleth SP. This allows continued use of the "hidden" IDP (e.g. for testing purposes) without showing the IDP publicly in the EDS interface. (Of course you'd need to provide other methods or documentation for the ones supposed to use such "hidden" IDPs.)

Hide IDPs that have asked not to be shown (Blacklist IDP discovery)

Here's a combined example of how to hide two specific IDPs by name from the EDS, as well as hiding all IDPs tagged with the REFEDS Hide-from-Discovery category:

...