Spørgsmål og svar

Her kan du finde svar på hyppigt stillede spørgsmål i forbindelse med serviceudbyderes tilslutning af løsninger til NemLog-in.

Målgruppen er teknisk personale hos myndighederne eller disses leverandører, som er i gang med en tilslutning.

Ofte stillede spørgsmål om NemLog-in

Digitaliseringsstyrelsen har etableret en NemLog-in support, der skal anvendes ved alle henvendelser om NemLog-in.

Supporten har mail adressen

Supporten vedligeholder en mailingliste, man kan blive tilknyttet (ved at sende kontaktoplysninger til ). Her udsendes løbende driftsmeddelelser og anden relevant information for serviceudbydere.

Ja, hvis borgerne skal logge på servicen / selvbetjeningsløsningen, skal der anvendes NemLog-in.

Hvis løsningen ikke har behov for at kende brugerens identitet (fx offentlige informationssider eller vejledninger), kan man undvære NemLog-in.

Ja, det er et krav til medlemmerne af føderationen. Se mere i tilslutningsguiden og OIOSAML profilen.

Bindings i metadataene

Når der valideres metadata, der indeholder POST-binding (SingleLogoutService Binding), vil validatoren melde fejl. På tidspunktet, hvor validatoren blev sat i produktion, kunne POST-binding ikke anvendes i NemLog-in. Dette er efterfølgende ændret, men ændringen er ikke blevet implementeret i validatoren. Der kan derfor godt indsendes metadata, uanset validatoren melder fejl, når fejlen skyldes, at der er angivet POST-binding.

Der kan indsendes metadata, hvor der er angives flere bindings: Redirect, POST og SOAP. Hvis der er angivet flere bindings, vil IDP'en anvende den først angivne. For at være sikker på, at den forventede binding anvendes, anbefales det, at der kun angives én binding i metadataene.

Efter version 2.0.8 af OIOSAML standarden, er det ikke længere et krav at understøtte common domain cookie.

Læs mere om OIOSAML standarden på Digitalisér.dk

Serviceudbydere kan hente NemLog-ins metadatafiler.

Serviceudbyderen skal fremsende egne metadata filer til og aftale et tidspunkt, hvor de vil blive importeret i integrationstestmiljøet.

Serviceudbyderen skal endvidere fremsende IP adresserne på servere til common domain.

På NemLog-in testportalen stilles en række test NemID medarbejdercertifikater (MOCES 2) til rådighed.

Bemærk at der ikke er knyttet rettigheder til disse certifikater.

Gå til testportalen

Det er også muligt at finde testcertifikater hos DanID

På NemLog-in testmiljøet er det kun muligt at logge på med OCES testcertifikater. Hvis der skal anvendes specifikke OCES testcertifikater, så certifikatet indeholder et specifikt CPR eller CVR nr., er det nødvendigt at anvende DanID’s test tools.

Læs mere om NemID tjenesteudbyder

Man kan logge på NemLog-in med alle OCES typer test og produktionscertifikater (dog ikke spærrede eller udløbne certifikater).

NemLog-in support udleverer SSL certifikater (et såkaldt wildcard / stjernecertifikat) inkl. private nøgler til common domain:

  • I test er det til domænet test-fobs.dk
  • I produktion er det til domænet fobs.dk

Endvidere kan NemLog-in support levere et OCES test virksomhedscertifikat til installation i myndighedens SAML produkt. Har man selv OCES virksomhedscertifikater til test, kan disse anvendes i stedet.

Serviceudbydere skal selv sørge for flg. certifikater:

  • SSL certifikat til produktion (f.eks. https://fiktivkommune.dk)
  • SSL certifikater til test
  • OCES virksomhedscertifikat til produktion (bestilles hos DanID)

I tilslutningsguiden (appendiks H) er der en mere detaljeret beskrivelse af de forskellige typer certifikater i løsningen.

Send en mail til med dit navn, organisation, mail, mobilnummer og EntityID (https://saml.) 

Ja, hvis man har eksisterende OCES eller SSL certifikater til egne web servere, kan disse i princippet genbruges. Dette gælder både test og produktion.

Af hensyn til funktionsadskillelse kan det dog være en fordel at operere med certifikater, der er separate fra andre løsninger.

Der er derfor truffet beslutning om, at der skal anvendes følgende, som udleveres af NemLog-in support:

  • virksomhedscertifikater og SSL-certifikater til test
  • SSL-certifikat for common domain til produktion

Nej, det tildeles af NemLog-in support/ CSC og vil rumme et løbenummer. Navnet vil ikke blive set af slutbrugeren.

Myndigheden skal oplyse IP adresse på serveren til FOBS support, hvorefter der foretages en DNS registrering i common domain af NemLog-in support/ CSC. Efter registrering er serviceudbyderens server med i det fælles domæne.

Nej, efter version 2.0.8 af OIOSAML standarden, er det ikke længere et krav at understøtte common domain cookie.

Common Domain cookie sættes af IdP’en og skal læses af serviceudbyderne (jer) i forbindelse med IdP discovery. 

SSL-certifikat til Common Domain kan rekvireres hos 

Af en række forskellige årsager må NemLog-in løsningens brugergrænseflade ikke indlejres i iFrames - hverken på portaler eller i serviceudbydernes egne applikationer.

Derfor bør portaler iflg. den fællesoffentlige integrationsmodel sørge for, brugeren har en session med NemLog-in før iFrames henter indhold fra løsninger, der kræver logon. Dermed vil logon til serviceudbyderen være en SSO operation, og NemLog-in vil ikke præsentere en brugergrænseflade i iFramen. Serviceudbyderen bør i kaldet til NemLog-in sætte attributten IsPassive=”true” på SAML beskeden for at signalere, at der ikke må vises en brugergrænseflade.

Ligeledes bør man ikke give brugeren mulighed for at aktivere Single Logout fra en iFrame. I stedet bør single logout ske fra portalernes hovedvindue.

Yderligere detaljer om brug af iFrames er indskrevet i portalintegrationsmodellen version 1.1 fra den Digitale Taskforce.

”Når vi nu engang er blevet færdige med test og har fået godkendt vores løsning, så skal vi have alle vore kunder i gang. Skal de hver især have lavet metadata, som skal indlæses i IDP’en? ”

Nej. Der er kun én metadatafil per databehandler/hosting leverandør, som godt kan gælde for flere myndigheder på én gang.

Hver serviceudbyder, der tilsluttes NemLog-in, skal tildeles et entydigt navn, der anvendes i kommunikationen med NemLog-in tjenesten. Kommunikationen sker via SAML 2.0 protokollen (nærmere betegnet den danske OIOSAML profil), og i denne protokol har parterne et unikt ID som kaldes ”entity ID”.

I OIOSAML profilen (version 2.0.5) angives nogle regler for opbygning af entity ID, som tager udgangspunkt i serviceudbyderens domæne. I princippet kunne entity ID’er også baseres på løbenumre, UUID’er osv. Hensigten med at basere navnekonvention på domænenavne er at sikre, at der tildeles unikke navne til serviceudbyderne, uden der er behov for central administration af ID’er hos Digitaliseringsstyrelsen.

Hvis en serviceudbyder anvender domænet ”bjergbykommune.dk”, foreskriver OIOSAML profilen at entity ID bliver ”https://saml.bjergbykommune.dk”. Bemærk at denne ID skal opfattes som et logisk navn og altså ikke angiver adressen (URL) på fysiske servere mv. De fysiske adresser på serviceudbydernes servere (SAML endepunkter) er beskrevet serviceudbyderens metadata fil.

Navnekonventionen i OIOSAML profilen tager ikke højde for situationer, hvor fx en kommune er tilknyttet flere forskellige SAML installationer. Dette kan eksempelvis forekomme, hvis kommunen køber forskellige it-løsninger, der OIOSAML parate, og som drives hos leverandøren. Det kunne eksempelvis være et system til elektroniske blanketter fra én leverandør og et system til on-line adgang til kommunens biblioteker fra en anden leverandør. Hvis disse to løsninger anvender forskellige servere til håndteringen af SAML protokollen, hvilket er sandsynligt, når de drives hos leverandørerne, er der behov for to forskellige entity ID’er.

Her kan det være relevant at inddrage underdomæner i entity ID’erne som fx:

  • https://saml.blanket.bjergbykommune.dk
  • https://saml.bibliotek.bjergbykommune.dk

I dette tilfælde angiver entity ID navnet på en SAML installation (hos leverandøren), og metadata filen rummer så de fysiske adresser på serverne i denne installation. Sagt på en anden måde er entity et kort navn for en metadata fil, som udpeger en SAML installation.

Bemærk at en SAML installation godt kan agere logintjeneste for flere forretningsapplikationer på en gang. Hvis kommunen f.eks. etablerer en SAML server i eget miljø, kan denne integreres med alle borgerapplikationer i kommunens miljø, og her er der så kun brug for et entity ID

Har du flere spørgsmål?

På Digitalisér.dk kan du få svar på flere spørgsmål angående NemLog-in.

Gå til Digitalisér.dk