Metadata Query Service (MDQ)

Pilotbetrieb - Nutzung auf eigene Gefahr!

Der Metadata Query Service befindet sich erst im Pilotbetrieb. Der DFN-Verein übernimmt keinerlei Gewähr hinsichtlich Verfügbarkeit, Fehlerfreiheit und Stablilität dieses Services. Erfahrungsberichte und Fehlermeldungen nimmt gerne das Team der DFN-AAI entgegen: hotline@aai.dfn.de.

Im Rahmen der SAML-basierten Kommunikation ermöglicht es der Metadata Query Service, die Metadaten der jeweiligen Gegenstelle (IdP/SP/Attribute Authority) in Echtzeit abzurufen, wobei hier i.d.R. auch ein Chaching stattfindet. Daher wird dieser Mechanismus auch als Per-Entity Metadata bezeichnet. Im Gegensatz zum traditionellen Verfahren, Föderationsmetadaten als große XML-Dateien zur Verfügung zu stellen, die von den jeweiligen technischen Instanzen heruntergeladen, validiert und weiterverarbeitet werden müssen, ist der Per-Entity Ansatz deutlich leichtgewichtiger und ressourcenschonender. IdPs, SPs und Attribute Authorities verarbeiten nur die Metadatdaten, die aktuell benötigt werden. Die Grundlage für dieses Verfahren bildet das Metadata Query Protocol (siehe unter Referenzen).
Es liegt in der Natur dieses Verfahrens, dass ein Metadata Query Service besonders hohen Anforderungen hinsichtlich Verfügbarkeit und Ausfallsicherheit genügen muss. Der Pilotbetrieb in der DFN-AAI dient dazu, diesbezügliche Erfahrungen zu sammeln, ggf. Verbesserungen vorzunehmen und den späteren Einsatz im Produktivbetrieb vorzubereiten.
Beachten Sie bitte auch die weiteren Hinweise unten.

Wichtiger Hinweis: Der MDQ-Service liefert keine lokalen Metadaten aus! Diese müssen nach wie vor über einen „statischen“ Metadata Provider des Typs FileBackedHTTPMetadataProvider (Shib IdP) bzw. XML (Shib SP) eingebunden werden.


URL für die Metadaten der Produktivföderation (DFN-AAI, DFN-AAI-Basic) und eduGAIN:

http(s)://mdq.aai.dfn.de

URL für die Metadaten der Testföderation (DFN-AAI-Test):

http(s)://mdq-test.aai.dfn.de

Zertifikat zur Überprüfung der Signatur der DFN-AAI MDQ Metadaten (PEM-Format)
SHA256 Fingerprint: 73:5B:9E:76:8A:A6:33:73:4D:3E:C6:D2:1E:98:B3:D9:03:74:B9:87:16:52:16:53:32:26:9A:B2:55:FC:CA:D2
https://www.aai.dfn.de/fileadmin/metadata/dfn-aai-mdq.pem


Produktivföderation (DFN-AAI, DFN-AAI-Basic) und eduGAIN

./conf/metadata-providers.xml
    <MetadataProvider id="dfn_aai_mdq_prod" xsi:type="DynamicHTTPMetadataProvider"
                  maxCacheDuration="PT1H" minCacheDuration="PT10M">
           <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
                  certificateFile="/etc/ssl/aai/dfn-aai-mdq.pem"/>
           <MetadataQueryProtocol>http://mdq.aai.dfn.de</MetadataQueryProtocol>
    </MetadataProvider>

Testföderation (DFN-AAI-Test)

./conf/metadata-providers.xml
    <MetadataProvider id="dfn_aai_mdq_test" xsi:type="DynamicHTTPMetadataProvider"
                  maxCacheDuration="PT1H" minCacheDuration="PT10M">
           <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
                  certificateFile="/etc/ssl/aai/dfn-aai-mdq.pem"/>
           <MetadataQueryProtocol>http://mdq-test.aai.dfn.de</MetadataQueryProtocol>
    </MetadataProvider>

Sonstige Filtermöglichkeiten werden gerne auf Anfrage dokumentiert.


Wichtiger Hinweis

Der Metadaten-Import via Metadata Query macht nur dann Sinn, wenn der Service Provider keinen Discovery Service verwendet, dessen IdP-Liste aus den importierten Föderationmetadaten generiert wird, wie dies beispielsweise beim Shibboleth EDS der Fall ist.


Produktivföderation (DFN-AAI, DFN-AAI-Basic) und eduGAIN

/etc/shibboleth/shibboleth2.xml
    <MetadataProvider type="MDQ" id="dfn_aai_mdq_prod" ignoreTransport="true"
                  cacheDirectory="mdq-aai-dfn-de"
                  maxCacheDuration="3600" minCacheDuration="600"
                  baseUrl="https://mdq.aai.dfn.de">
           <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai-mdq.pem"/>
    </MetadataProvider>


Ausschließlich IdPs aus DFN-AAI Advanced

(Zur Unterscheidung zwischen „Advanced“ und „Basic“ siehe die Erläuterungen zu den Verlässlichkeitsklassen)

Wichtig: damit der u.g. Filter funktioniert, muss im Root-Element SPConfig der Datei shibboleth2.xml der Namespace xmlns:saml=„urn:oasis:names:tc:SAML:2.0:assertion“ gesetzt sein.

/etc/shibboleth/shibboleth2.xml
    <MetadataProvider type="MDQ" id="dfn_aai_mdq_advanced_only" ignoreTransport="true"
                  cacheDirectory="mdq-aai-dfn-de"
                  maxCacheDuration="3600" minCacheDuration="600"
                  baseUrl="https://mdq.aai.dfn.de">
           <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai-mdq.pem"/>
           <MetadataFilter type="Include" matcher="EntityAttributes">
               <saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                 <saml:AttributeValue>advanced</saml:AttributeValue>
               </saml:Attribute>
           </MetadataFilter>
    </MetadataProvider>

Weitere Filtermöglichkeiten werden gerne auf Anfrage dokumentiert.


Allgemein:
Sofern in der Metadata Provider Konfiguration weitere, 'statische' (z.B. FileBackedHTTPMetadataProvider) MetadataProvider definiert sind, sollten MetadataProvider-Elemente des Typs das MDQ bzw. DynamicHTTPMetadataProvider ganz am Ende eingefügt werden. Ansonsten führt der IdP/SP jedes Mal eine Metadata Query aus, auch wenn die betreffende Entity bereits über die statischen Metadaten verfügbar ist.

Shibboleth IdP:
Bei nicht erfolgreichen Metadata Queries erscheint eine Warnung im Log: Document root was not an EntityDescriptor: org.opensaml.saml.saml2.metadata.impl.EntitiesDescriptorImpl

Shibboleth SP < 3.2.0:
Im SP-Log erscheint nach jedem Neustart die irreführende Warnung, dass das Caching-Verzeichnis nicht nicht angelegt werden kann. Es existiert bereits. Siehe https://issues.shibboleth.net/jira/browse/SSPCPP-916

Sonstige Fehler bitte an hotline@aai.dfn.de melden.


  • Zuletzt geändert: vor 4 Wochen