SAML metadata

SAML Metadata is een gestandaardiseerd XML-document dat alle technische informatie van die ene partij definieert

Bij de integratie via SAML 2.0 stellen beide partijen (de SP en de IDP) een XML-document op waarin alle relevante informatie staat voor de integratie. Hoe deze metadata eruit moet zien, werd door Oasis beschreven in de SAML metadata standaard.

De SAML metadata bevat uitsluitend publieke informatie met daarin onder meer:

  • de entityID: een unieke identifier voor deze partij
  • de certificaten (enkel het publieke deel) die gebruikt worden voor signing en encryptie
  • de ondersteunde bindings en NameID formaten
  • de URL’s voor Single Logout (zie de rubriek omtrent “Afmelden”)
  • de AssertionConsumerService URL (in geval van de SP): dit is de URL waarnaar de SAML Response teruggestuurd zal worden na de authenticatie
  • maar ook parameters om het verwachte gedrag van de tegenpartij aan te geven, bvb. WantAssertionsSigned (true/false), WantAuthnRequestsSigned (true/false), AuthnRequestsSigned (true/false), , …

Aangezien het over publieke informatie handelt, kan deze informatie via mail uitgewisseld worden.

SAML metadata van de ACM Identity Provider

De SAML metadata van de ACM IDP van Toegangsbeheer is publiek toegankelijk:

SAML metadata van de Service Provider (= de toepassing)

Het merendeel van de toepassingen/libraries beschikt over de mogelijkheid om na de configuratie van de SAML service provider de metadata te exporteren. Bij de integratie dient deze SAML metadata aan het integratieteam bezorgd te worden.

Het spreekt voor zich dat na iedere configuratiewijziging (gerelateerd aan de SAML-setup) deze SAML-metadata opnieuw ge├źxporteerd en ge├»mplementeerd moet worden langs de IDP-zijde.

In het uitzonderlijke geval waar er geen export-mogelijkheid beschikbaar is in de toepassing/library kan u hieronder een voorbeeld terugvinden waarin de belangrijkste elementen staan opgenomen. Het hergebruik van zulke template heeft als risico dat het gedrag van de SAML service provider anders zal zijn dan de interpretatie van diegene die de metadata manueel samenstelt en dat er problemen kunnen optreden bij de integratie van de toepassing.

<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor entityID="AAA" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>
                       BBB
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>
                       CCC
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
            <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
            </EncryptionMethod>
        </KeyDescriptor>
        <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="DDD"/>
        <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="EEE"/>
        <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
        <AssertionConsumerService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="FFF"/>
    </SPSSODescriptor>
</EntityDescriptor>

Volgende “placeholders” moeten uiteraard vervangen worden:

  • AAA: de entityID is een unieke identifier voor deze service provider: deze begint best met de URL van de toepassing
  • BBB: het certificaat dat door de SP gebruikt zal worden voor de signing van het SAML AuthnRequest (en waarmee de IDP dus de SP identificeert)
  • CCC: het certificaat dat gebruikt zal worden door de IDP voor de encryptie van de assertion/attributen: dit is optioneel, doch sterk aanbevolen
  • DDD: de single logout (SLO) URL in geval van de HTTP-redirect binding
  • EEE: de single logout (SLO) URL in geval van de HTTP-POST binding
  • FFF: de AssertionConsumerService URL is de URL waar de IDP de SAML Response na de authenticatie naartoe zal sturen