Versions Compared

Key

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

...

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 an a combined example of how to hide two specific IDPs by name from the EDS, and hide as well as hiding all IDPs tagged with the REFEDS Hide-from-Discovery category:

Code Block
languagehtml/xml
<MetadataProvider type="XML" url="http://eduid.at/md/aconet-registered.xml" ...>
    <MetadataFilter ...>
    <DiscoveryFilter type="Blacklist" matcher="Name" Name="https://idp.example.org/shibboleth"/>
    <DiscoveryFilter type="Blacklist" matcher="Name" Name="https://another.idp.example.org/shibboleth"/>
    <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" 
      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>
Note

Note that a DiscoveryFilter will not prevent use of matching IDPs with the local SP! The only result of a discovery filter is filtering the output of the Shibboleth SP's "DiscoFeed" JSON resource that is used by the Shibboleth Embedded Discovery Service (but can be used by others as well, of course).  If you want to prevent the SP from federating with certain IDPs (or groups of IDPs) – as some kind of initial coarse access control – use a MetadataFilter instead (like in the examples above).