Zo werkt het
- 1 Plak de metadata-XML, kies of sleep een XML-bestand, of kies “Ophalen via URL” en vul het https-adres van de metadata in.
- 2 Klik op “Metadata valideren”.
- 3 Lees de samenvatting, los de fouten en waarschuwingen op – elke controle noemt de paragraaf in eID SAML 4.4 – en valideer opnieuw.
Wat de validator controleert
De validator volgt de Koppelvlakspecificatie eID SAML 4.4, het SAML-profiel voor dienstverleners in het Nederlandse eID-stelsel (entityID’s met urn:nl-eid-gdi). Elk resultaat noemt de paragraaf waar het op gebaseerd is.
- XML en schema – geldige XML, het OASIS SAML 2.0-metadataschema, unieke ID-attributen en de metadata-namespace.
- Document – een ID op het root-element,
validUntilofcacheDuration, één SPSSODescriptor, enAuthnRequestsSignedenWantAssertionsSignedop true. - Sleutels en certificaten – een KeyDescriptor voor ondertekenen en een voor versleutelen, met KeyName en X509Certificate; PKIoverheid-uitgever, sleutels van minstens 2048 bits, geldigheid, sleutelgebruik, de PKIoverheid-certificaatpolicy en het OIN in het certificaat.
- Handtekening – een enveloped signature op het root-element met exclusieve canonicalisatie, RSA-SHA256 of sterker en een SHA-256-digest, cryptografisch gecontroleerd met het ondertekencertificaat uit de metadata.
- entityID – de vorm
urn:nl-eid-gdi:1.0:<ROL>:<OIN>:entities:<index>, een SP-rol (DV of LC), een index van 4 cijfers (9000-9999 is voor testsystemen) en hetzelfde OIN als het ondertekencertificaat. - Endpoints en diensten – AssertionConsumerService met de HTTP-Artifact-binding, unieke indexen en één standaard; SingleLogoutService met HTTP-POST; AttributeConsumingService met ServiceName en een ServiceUUID; elke URL via openbare https.
- Algoritmen – geen SHA-1 of ECDSA; AES-256-CBC en RSA-OAEP voor versleuteling.
DV-metadata en LC-bundels
Een dienstverlener (DV) publiceert een EntityDescriptor. Een leverancier clusteraansluiting (LC) publiceert een EntitiesDescriptor met een eigen LC-entiteit en een entiteit per aangesloten DV. Bij een bundel controleert de validator ook dat er precies één LC-entiteit is, minstens één DV-entiteit, geen dubbele entityID’s, en dat de bundel is ondertekend met het certificaat van de LC.
Wat niet gecontroleerd wordt
De handtekening wordt gecontroleerd met het certificaat uit de metadata, maar de certificaatketen wordt niet gecontroleerd tegen de PKIoverheid-roots, en of een certificaat PKIoverheid is, wordt afgeleid uit de uitgever. Een schoon resultaat helpt bij de voorbereiding, maar vervangt de aansluittest van je makelaar of de autoriteit niet.
Privacy
Metadata is openbare informatie. Geplakte en geüploade metadata wordt op onze server gevalideerd en niet bewaard. URL’s worden alleen via https en alleen van openbare internetadressen opgehaald.
Bronnen
Veelgestelde vragen
Welke metadata kan ik valideren?
Metadata van service providers: een EntityDescriptor van een dienstverlener (DV), of een EntitiesDescriptor van een leverancier clusteraansluiting (LC) met de DV-entiteiten.
Waarom is de handtekening geldig, maar het vertrouwen in het certificaat alleen een waarschuwing?
De validator controleert de handtekening met het certificaat uit de metadata, maar niet de keten van dat certificaat tot de PKIoverheid-root. Controleer dat apart.
Wat betekent de entityID-index 9000-9999?
Indexen 0000-8999 zijn voor productiesystemen; 9000-9999 zijn gereserveerd voor testsystemen.
Wordt mijn metadata bewaard?
Nee. Ze wordt gevalideerd en daarna weggegooid. Gebruik de URL-optie om gepubliceerde metadata direct te valideren.
Hoe groot mag de metadata zijn?
Tot 10 MB, genoeg voor LC-bundels met veel DV’s.
Laatst bijgewerkt: