Loading…
Tilbage

Hent NemLog-in Produktion IDP metadata der benyttes fra 25. september 2014 kl. 9.00


05-09-2014 11:58:18

Kære serviceudbydere og it-leverandører på NemLog-in

NemLog-in IDP-produktionscertifikat udskiftes, da det udløber den 1. oktober 2014, og det betyder, at der nu kommer en opgave til jer med at forberede skiftet til det nye certifikat.


Hvad skal der gøres?

Det er en opgave der kræver, at alle løsninger der er tilsluttet NemLog-in, skal skifte deres metadata, så det indeholder det nye certifikat. Selve øvelsen har ikke et stort omfang, men for nogle af jer kræver det, at I koordinerer med jeres leverandør.
Udfordringen er, at når vi i NemLog-in skifter IDP-certifikatet, skal i samtidigt skifte til det nye IDP-certifikat. Skiftet til det nye IDP-certifikat skal ske synkront, da jeres løsning ellers ikke vil virke på NemLog-in. I det tidsrum hvor skiftet finder sted, vil det ikke være muligt at logge på jeres løsning.
I forbindelses med skiftet, skal i være opmærksom på, at det nye IDP-certifikat er et OCES2 certifikat. Det kan betyde, at i skal tilføje nye rodcertifikater for at opnå trust til OCES2 CA. Mange løsninger anvender dog allerede OCES2 certifikater i deres tilslutning til NemLog-in, men for nogle kan skiftet til OCES2 betyde, at der er behov for at teste tilslutningen til NemLog-in. NemLog-in support anbefaler at vurdere om skiftet til OCES2 kan udgøre en risiko for driftsforstyrrelse og evt. at teste skiftet på NemLog-in testmiljøet. (http://digitaliser.dk/resource/2632411)
De nye metadata ligger på denne side og findes i en OIOSaml version og en virk legacy version.

Metadata er envidere tilgængelige på NemLog-ins test portal: https://test-nemlog-in.dk/testportal/

Du kan også hente produktion OCES2 (TRUST2408) rodcertifikater til på www.nets.eu.

Hvornår skal det gøres?

Skiftet er planlagt til at finde sted torsdag d. 25. september 2014 kl. 9.00 – det er altså her i skal stå klar til at foretage skiftet for at undgå driftsforstyrrelser. Der vil forud for skiftet være et Lukkevindue fra kl. 6.00 til 9.00. NemLog-in vil ikke være tilgængeligt i dette tidsrum.


Eventuelle spørgsmål kan sendes til NemLog-in support på nemlogin@digst.dk.


Venlig hilsen
NemLog-in support

Filer og referencer

Titel Type
Prod-nemlog-in-2-2014.xml text/xml
Prod-nemlog-in-2Virk-2014.xml text/xml
Profilbillede

What to do

Jens Nielsen

Hej Jeppe

Jeg er ikke bekendt med hvilke NemLog-in adgange vi har i kommunen.

Dvs. jeg er heller ikke bevidst om, hvad der skal gøres den 25. sept.

Kan du give mig nogle eksempler på adgange der skal opdateres?

Mvh. Jens Nielsen

Tårnby Kommune

Profilbillede

Nye metadata er nu tilgængelige

Jeppe Lundfald

Prod-nemlog-in-2-2014.xml er OIOSaml versionen

Prod-nemlog-in-2Virk-2014.xml er Virk legacy versionen.

Venlig hilsen
NemLog-in support

Profilbillede

Forslag til forbedringer - vi kan gøre det bedre

Søren Nielsen

Tak for info, det finder vi fint ud af.

Men det er ikke for at være negativ, men kunne vi ikke lave disse skift lidt bedre?

Hele det offentlige danmark er jo nede den dag, og en god del hosting firmaer/konsulenter har et stykke arbejde den dag, som de ikke har haft mulighed for at planlægge. De forskellige NemLog-in løsninger har helt sikkert forskellige tidspunkter der er kritiske for dem, det kan nemt være at de hellere ville have lavet skiftet på et andet mere opportunt tidspunkt.

Næste gang:

Forslag - Hvad med at lave lidt om i jeres metadata fil, så den peger mod et par nye endpoints f.eks. https://login.nemlog-in.dk/adfs/ls/2015/ i stedet for https://login.nemlog-in.dk/adfs/ls/.

Det gamle endpoint bruger det gamle certifikat, det andet bruger det nye certifikat. Så åbner I på en ret nem måde at vi har en glidende overgangsperiode, hvor løsninger stille og roligt kan skifte over.

Hvis vi yderligere fik 2-3 måneder, så er jeg sikker på at alle kan benytte allerede eksisterende service vinduer.

Næste gang kunne vi kalde den https://login.nemlog-in.dk/adfs/ls/2017/.

Tak Søren, 

Det er dejligt at nogen tager sig tid og kommer med nye ideer og indfaldsvinkler. Jeg har forespurgt vores teknikkere og bedt dem give en umiddelbar tilkendegivelse.

Uden at have undersøgt det nærmere, så er det ikke muligt at have mappet url’er til forskellige certifikater – uden at der skal etableres et nyt ADFS miljø. Muligvis vil ADFS certificate rollover funktionaliteten kunne anvendes, men det er ikke noget der er undersøgt eller testet: 

http://social.msdn.microsoft.com/Forums/vstudio/en-US/47671c9e-5b96-4baf-8e90-588b6670abc1/adfs-replacing-tokensigning-cert-impact-on-relying-party?forum=Geneva 

Umiddelbart er det ikke muligt med den nuværende ADFS løsning at anvende to certifikater samtidigt, da requests kun vil blive signeret med det ”aktive” certifikat. Endvidere skal det afklares om SAML understøtter at man kan angive flere signeringscertifikater i metadata og at man i sin request kan specificere hvilket et af certifikaterne som der skal signeres med, subsidiært at ADFS signerer svaret med begge certifikater. Ligeledes er der en risiko for at eksisterende løsninger hos service udbydere ikke kan håndtere 2 certifikater og derfor først skal ændres for at understøtte en sådan løsning.   

Med venlig hilsen

Eddie Moordieck,

NNIT Service Delivery Manager

Hej Eddie

Tak for hurtigt svar.

Jeg er ret sikker på at ADFS primary/secondary kun gør det nemmere at skifte certifikat i jeres ende. Hvis det skal fungere seamless, så er det (vist) noget med et I skal sætte en grace period op, hvor min ADFS relying party (jeg skal så have en fuld ADFS) automatisk kan hente fra i grace period. Min forståelse er at serveren vælger at lade være at kryptere (men kun signere) i denne periode, som normalt varer en uge.

Helt oplagt er jeg ikke 100% sikker i ovenstående, og jeg tror det vil være undtagelsen hvis jeres NemLog-in systemer har en fuld ADFS server tilknyttet (hvis den konfiguration overhovedet er mulig). 

Jeg er tilgengæld ret sikker på at du ikke kan benytte SAML til at angive certifikatet der anvendes, sålænge I (og vi) kryptere SAML kommunikationen. Inde i SAML assertion/requests står der godt nok certifikat informationer, men de kan naturligvis kun læses hvis den ikke er krypteret, eller hvis man kender nøglen. 

Derfor: Hvis I vil benytte SAML til at hjælpe med skiftet, så er I nødt til at køre ukrypterede tokens i overgangs perioden.

Sikkerhedsmæssigt synes jeg ikke det er så stor en risiko, men I har sikkert en anden holdning ;-)

Min indgangsvinkel med en anden endpoint adresse, ville løse hovedpinen med certifikat overlap og manglende krypteringer. Men det kræver godt nok lidt arbjede fra jeres side. Jeg er ikke helt stiv i hvordan man opsætter flere endpoints i ADFS, men det vil enten kræve et nyt særskilt adfs miljø, eller et endpoint mere på jeres eksisterende.