Nu skal WAYFs deltagere konfigurere nye kryptonøgler

Af Mikkel Hald, 16/12/25

Artiklen her indeholder vigtig information til organisationer som deltager i WAYF, og bør læses omhyggeligt af deres WAYF-ansvarlige.

Hvis man har en integration til WAYF, enten som tjeneste­udbyder eller bruger­organisation, er det helt generelt ikke nødvendigt at ændre i sin lokale opsætning på noget tidspunkt når integrationen én gang er gennemført. Men en meget sjælden gang imellem er det faktisk nødvendigt; og sådan en gang står for døren her i tiden frem mod foråret 2026.

Her udfaser vi nemlig vores nuværende signerings- og krypterings­nøglepar og erstatter det nøglepar med to nye: et til signering og et til kryptering. Online­systemer med login- eller logout­trafik gennem WAYF har brug for at kende den offentlige nøgle i hvert nøglepar for at kunne hhv. validere signaturen på trafik fra WAYF og XML-kryptere trafik til WAYF. Hvis man har en integration til WAYF, får man derfor nu en opgave med at anskaffe de nye nøgler og konfigurere dem i sin opsætning for WAYF – senest 28. februar 2026. Indtil da vil både den gamle og de nye nøgler fungere; og de nye er i drift, så man kan skifte allerede nu – og bør gøre det snarest muligt. Afhængigt af hvilken software man bruger over for WAYF, kan det nemlig være nødvendigt at man konfigurerer WAYFs nye nøgler i sin opsætning allerede senest 31. december 2025. Nedenfor forklarer vi dét nærmere og anviser hvad man helt konkret skal gøre, alt efter hvilken slags integration man har til WAYF.

Hvorfor skifter vi nøgler?

RSA-2048
REJECTED

Alene for at opretholde den sikkerhed som er forbundet med nøglernes længde. Nøglerne i WAYFs nuværende (RSA-)nøglepar er 2048 bits lange, hvilket endnu regnes for tilstrækkeligt sikkert; men pga. voksende angrebs­kapacitet i form af hurtigere computere og forbedrede algoritmer er det blevet normen at bruge lidt længere nøgler, og vores to nye er på hver 3072 bits. Nøgler er imidlertid uforholds­mæssigt langsommere i brug jo længere de er, hvilket er grunden til vi først nu skrider til forlængelse.

Teoretisk kan det også være en smule sikrere ikke at bruge samme nøglepar til både signering og kryptering; så derfor indfører vi i samme moment distinkte nøglepar til hvert formål.

RSA-3072
ACCEPTED

Derimod handler nøgle­skiftet på ingen måde om at imødegå at privat­nøglen skulle være blevet stjålet. Det kan nemlig ikke være sket, og vil heller ikke kunne ske med de nye, for alle WAYFs privat­nøgler ligger i en HSM. Derfor skifter vi kun meget sjældent nøgler – og forventer da heller ikke at skifte nøgler igen før selve krypto­algoritmerne om nogle år vil skulle erstattes med kvantesikre algoritmer.

I stedet for at forlænge RSA-nøglerne, kunne man selvfølgelig opnå bedre sikkerhed ved at gå helt væk fra RSA og over til sikrere algoritmer og nøgle­typer af Elliptical Curve-familien. Men det understøttes desværre ikke i ret meget SSO-software endnu.

Hvad det her ikke handler om

Inden vi går videre, skynder vi os for klarheds skyld at gøre opmærksom på to ting som artiklen her ikke drejer sig om.

Den ene er TLS-certifikater: De nøgler (og “certifikater”) vi her taler om at udskifte, har intet med TLS at gøre. Her er tale om særskilte nøgler eller X.509-objekter som føderations­protokollerne (SAML og OIDC) opererer med.

En anden ting artiklen her ikke drejer sig om, er: de krypto­nøgler din organisation selv danner og bruger i sine integrationer med WAYF. Det handler her alene om nøgler som stammer fra WAYF – og som I skal konfigurere i jeres WAYF-integrationer.

Hvordan tager man de nye nøgler i brug?

Det gør man helt overordnet ved at opdatere sine systemers metadata for WAYF. Herunder kan du se hvad din organisation konkret skal gøre for at indarbejde WAYFs nye krypto­nøgler, afhængigt af hvordan din organisation deltager i WAYF:

Hvis din organisation er bruger­organisation i WAYF

Hvis din organisation står på listen her, er den bruger­organisation i WAYF. Og så behøver du slet ikke foretage dig noget – medmindre jeres identity provider (“IdP”) krypterer sine assertions til WAYF, eller du ikke er sikker på at jeres IdP-software accepterer at have en SSO-nøgle med overskreden dato i X.509-strukturens notAfter-felt som eneste nøgle i opsætningen for en given service provider. Desværre ses en del IdP-software nemlig at behandle SSO-nøgler som egentlige certifikater og håndhæve den udløbs­dato der måtte være skrevet ind i X.509-strukturen, til trods for at dét ikke er tilladt ifølge SAML-profilerne for inter­operabilitet. Har man sådan en software, skal man opdatere dens WAYF-opsætning senest 31. december 2025, for da “udløber” WAYFs nuværende “certifikat” for signatur­validering og kryptering. Vi anbefaler at man i alle tilfælde og snarest muligt opdaterer sin IdPs WAYF-opsætning – sådan her:

  • Hvis URL'en https://metadata.wayf.dk/wayf-metadata.xml fremgår af jeres WAYF-opsætning, og jeres IdP ikke er en ADFS:
    • Hvis du er sikker på jeres IdP jævnligt læser URL'en automatisk, skal du intet foretage dig.
    • Ellers skal du manuelt sørge for at jeres IdP læser URL'en på ny. Forinden bør du sikre dig at din software ikke derved overskriver opsætningen af hvilke attributter I sender til WAYF.
  • Ellers skal du redigere jeres IdPs WAYF-opsætning manuelt – sådan her:
    • Du skal erstatte værdien https://wayf.wayf.dk/module.php/saml/sp/saml2-logout.php/wayf.wayf.dk med værdien https://wayf.wayf.dk/saml2/spslo3 [].
    • Det kan sagtens være jeres IdP slet ikke har nogen nøgler konfigureret for WAYF; og så behøver du ikke (og bør ikke) ændre noget mht. nøgler. Men hvis den har en nøgle for WAYF, så skal du gøre følgende:
      • Hvis jeres konfiguration har en krypterings­nøgle (et krypterings“-certifikat”) for WAYF, så skal du erstatte den nuværende nøgle med værdien du får ved at klikke her: []. Du kan også få den nye nøgle som fil hvis din konfiguration kræver det.
      • Hvis jeres konfiguration har en nøgle (et “certifikat”) til signatur­validering, så skal du til konfigurationen tilføje nøglen du får ved at klikke her: []. Du kan også få den nye nøgle som fil hvis din konfiguration kræver det. Hvis du konfigurerer nøglen til signatur­validering, er det vigtigt at du sørger for at jeres IdP stadig ikke validerer signatur på AuthnRequests fra WAYF; WAYF signerer nemlig kun logout­meddelelser og ikke login­forespørgsler.
    • Hvis jeres IdP er en ADFS, skal du sørge for at slå automatisk opdatering af metadata fra.

Hvis du ikke selv har adgang til at redigere WAYF-opsætningen i din organisations IdP, så skal du bede jeres it-leverandør om at forholde sig til ovenstående og gøre det af det som måtte være nødvendigt.

Selvom din organisation primært er bruger­organisation i WAYF, skal du være opmærksom på at den muligvis også er ansvarlig for WAYF-opsætningen i en eller flere tjenester som modtager autentifikationer fra WAYF eller specifikt fra jeres egen IdP via WAYF (fx en instans af LinkedIn Learning, Zoom eller TimeEdit). Det er tilfældet hvis det i sin tid var jer der satte SSO op i tjenesten eller meddelte tjenestens leverandør SSO-konfigurationen for WAYF. I så fald er den gule sektion herunder for tjeneste­udbydere desværre også relevant for dig.

Hvis I ligefrem selv driver en tjeneste, er I naturligvis ansvarlige for opdateringen af WAYF-opsætningen i den; men det kan også dreje sig om kommercielle tjenester I har købt, hvor opsætningen for SSO peger på jeres IdP via WAYF (såsom en Zoom-instans eller et learning management-system). I hver tjeneste af den slags har I muligvis selv adgang til at redigere SSO-indstillingerne, men skal ellers henlede leverandørens opmærksomhed på sektionen for tjeneste­udbydere herunder og få leverandøren til at redigere dem for jer. Hvis I ikke har et fuldstændigt overblik over hvilke tjenester det måtte dreje sig om, skal I ikke fortvivle; for WAYF-sekretariatet kan se og holder øje med hvilke tjenester der endnu ikke bruger de nye nøgler, og tager fat i de tjeneste­ansvarlige løbende. Det kan også hjælpe til et overblik at logge ind på WAYFs statistiktjeneste og se hvilke tjenester I bruger. Langt de fleste af dem forvaltes af andre; men I vil ved at se på listen kunne komme i tanker om hvilke I selv har ansvaret for SSO-opsætningen af.

Instanser af Kaltura, Panopto og Zoom tager DeiC sig i udgangspunktet af at redigere WAYF-opsætningen i. Derudover er følgende tjenester allerede blevet opdateret: Statens SSO, mange instanser af Pure og MoveOn, tjenester fra Arcanic. TimeEdit er i gang.

Øvrige anbefalinger

Vi anbefaler jer i øvrigt at bruge føderationen som SSO til så mange af jeres tjenester som muligt, fx SKI og Statens SSO. Det giver, med helt samme bruger­oplevelse som ellers og med brug af åbne standarder udviklet i det internationale forsknings- og uddannelsesmiljø, mindre integrations­arbejde og mindre løbende vedligehold og sætter jer i stand til at skifte krypto­nøgler og endda hele jeres login­system over for tjenesterne uden at skulle koordinere det med hver udbyder. Og udbyderne er alle underlagt føderationens regler for bl.a. interoperabilitet, dataminimering og god it-skik. WAYF er en del af det offentlige og er først og fremmest en forening og kun i anden række en teknisk infrastruktur. Og WAYF-sekretariatet rådgiver og hjælper gerne, fx med at få SSO til at virke med nye tjenester. Få mest muligt ud af jeres WAYF-deltagelse.

Hvis din organisation er tjeneste­udbyder i WAYF

Hvis din organisation i rollen som tjeneste­leverandør eller -udbyder modtager logins fra en eller flere tekniske identity providers (“IdP'er”) i WAYF, så skal du for hver IdP-opsætning du har i din(e) service provider(s), gøre som forklaret herunder – snarest muligt og senest 28. februar 2026. Hvis din SSO-software (i strid med specifikationen) ikke accepterer SSO-nøgler med overskreden dato i X.509-strukturens notAfter-felt, skal du endda gøre det senest 31. december 2025; for da “udløber” WAYFs nuværende “certifikat” for signatur­validering og kryptering. Desværre ses en del SSO-biblioteker at behandle SSO-nøgler som egentlige certifikater og håndhæve den udløbs­dato der måtte være skrevet ind i X.509-strukturen, til trods for at dét ikke er tilladt ifølge SAML-profilerne for inter­operabilitet. Fordi kun nøglen betyder noget, følger det også af profilen at en tjeneste ikke må basere sin signatur­validering på et fingeraftryk af hele certifikatet som medsendes i hver assertion, kun på et af selve nøglen. For hver IdP-opsætning du råder over, skal du gøre følgende:

Hvis integrationen bruger SAML2-protokollen

I det tilfælde skal du sandsynligvis ændre lidt i opsætningen, afhængigt af hvordan den fungerer:

  • Hvis en af følgende URL'er optræder i IdP-opsætningen, og din service provider ikke er en ADFS: — så skal du (medmindre det er en ADFS du har) gøre ét af to:
    • Hvis din applikation jævnligt læser URL'en automatisk, skal du intet foretage dig.
    • Ellers skal du manuelt sørge for at applikationen læser URL'en på ny. Slå i øvrigt automatisk opdatering til hvis det er muligt.
    Hvis det herefter ikke virker, er det måske fordi dit system ikke udnytter al informationen det har læst på URL'en. Du skal sikre dig at dit system ikke kun opdaterer selve krypto­nøglerne, men også de URL'er det skal kontakte WAYF på. Det er en alvorlig programmerings­fejl hvis systemet ignorerer elementer af de SAML-metadata det læser fra sin identity provider; det er ikke tilladt, i og med at metadata­dokumentet efter specifikationen er en samlet opskrift for hvordan ens system skal kommunikere med IdP'en. Du kan få integrationen til at virke igen ved at følge instruktionerne for manuel opdatering herunder:
  • Ellers (altså hvis ingen af URL'erne herover optræder, eller din service provider er en ADFS) skal du redigere IdP-opsætningen manuelt – på én af to måder:
    • Hvis der i din opsætning optræder URL'er som indeholder udtrykket birk.php:
      • Du skal i hver URL med birk.php erstatte birk.php med birk3 [].
      • Du skal erstatte den nuværende nøgle til signatur­validering med den tilsvarende værdi i dokumentet der ligger på https://wayf.wayf.dk/MDQ/<domæne>/idp/<domæne>, hvor du i stedet for <domæne> skal indsætte fx cbs.dk for Copenhagen Business School osv., altså institutionens domænenavn. Værdien du skal bruge, er den lange streng som begynder med MII, i KeyDescriptor-elementet med XML-attributten use sat til signing.
    • Ellers (hvis du ingen URL'er har med birk.php i) skal du gøre sådan her:
    • Hvis din service provider er en ADFS, skal du sørge for at slå automatisk opdatering af metadata fra.

Og så er du færdig. Men det er vigtigt at du i en manuel opdatering fuldfører alle trinene og ikke kun opdaterer selve nøglen.

Hvis integrationen bruger faciliteten SAML2jwt

Hvis din integration bruger WAYFs særlige SAML2jwt-facilitet, skal du senest 28. februar 2026 udføre følgende to ændringer i din applikation:

Men i øvrigt ønsker WAYF at udfase SAML2jwt og anbefaler at du skifter til den mere standardiserede protokol OIDC, som minder meget om SAML2jwt.

Hvis integrationen bruger OIDC-protokollen

Her forudsætter vi at din integration hvis den har brug for krypto­nøgler fra WAYF, læser de relevante OpenID Provider-konfigurationer fra WAYF dynamisk og dermed selv skaffer sig de nye nøgler efter behov. Du skal derfor intet foretage dig. Men henvend dig straks til WAYF-sekretariatet hvis du mod forventning skulle opleve problemer her i perioden for nøgle­skiftet.

Øvrige anbefalinger

Vi anbefaler dig i øvrigt at bruge WAYF til SSO med så mange institutioner som muligt, herunder alle relevante på listen her og i eduGAIN. Det giver mindre arbejde på begge sider af forbindelserne og sikrere interoperabilitet, med brug af åbne standarder udviklet i det internationale forsknings- og uddannelsesmiljø. Vi anbefaler også at du i relevant omfang bruger RA21-standarden for signalering og aktivering af institutions­login – som giver optimal bruger­oplevelse og abstraherer fra specifikke IDM-leverandører hos institutionerne. Standarden bruges bl.a. af Uddannelses- og Forskningsstyrelsen. WAYF-sekretariatet rådgiver og hjælper gerne. WAYF er en del af det offentlige og er først og fremmest en forening, kun i anden række en teknisk infrastruktur. Få mest muligt ud af jeres WAYF-medlemskab.

Hvis din organisation modtager logins fra danske eller islandske institutioner gennem eduGAIN

Det er vigtigt at du i hver af dine service providers (hver af dine SAML2-SP'er) opdaterer metadata fra den eduGAIN-føderation din SP er medlem af. Det kan fx være britiske UK Access Management Federation, tyske DFN-AAI eller amerikanske InCommon – det ved du selv. Men du skal sørge for at opdatere metadata herfra inden 1. januar 2026, for ellers holder fødereret SSO fra dine danske eller nord­atlantiske kunde­institutioner muligvis op med at virke den dag. Hvis dit system (som det bør) automatisk opdaterer metadata fra din føderation med jævne mellemrum, skal du naturligvis ikke foretage dig noget.

Hvis du ikke læser din danske eller islandske kunde­institutions IdP-metadata fra din nationale føderation, men i stedet fra en URL institutionen har givet dig (begynder med https://wayf.wayf.dk/MDQ/), så kan du i stedet opdatere institutionens metadata fra den URL – og bør gøre det inden 1. januar 2026. Hvis din software overholder reglerne for håndtering af krypto­nøgler i SAML-profilerne for inter­operabilitet, kan du vente helt til 28. februar 2026 med at opdatere metadata. Hvis dit system automatisk opdaterer metadata fra kundens URL med jævne mellemrum, skal du intet foretage dig.

Tags: 
nøgleskift
rsa
sso-nøgle
kryptonøgle
saml
oidc