DevTest4-miljøet (pre-produktionsmiljøet): Tekniske oplysninger

DevTest4-miljøet (pre-produktionsmiljøet) skal som udgangspunkt bruges til at teste jeres eksisterende it-systemer i NemLog-in i forhold til nye eller kommende funktioner, som er på vej til at blive tilføjet i NemLog-in.

Nye funktioner i NemLog-in er som udgangspunkt tilgængelige allerede nogle uger, før de kommer i drift i produktionsmiljøet. 

DevTest4-miljøet (pre-produktionsmiljøet) består af 2 ben:

• produktionsbenet
• integrationstestbenet.

NemLog-in anbefaler, at I som udgangspunkt bruger integrationstestbenet, da det i er nemmere at opsætte testorganisationer. Kodebasen er den samme for produktionsbenet og integrationstestbenet.

Bemærk, at nogle komponenter er tilgængelige i begge ben, mens andre kun er tilgængelige i det ene ben. Læs nærmere nedenfor.

I kan hente miljøoversigten som PDF her:

DevTest4 (pre-produktionsmiljø) miljøoversigt (pdf)

Hvis I ønsker at teste jeres integration af jeres nye it-system med NemLog-in, skal I bruge integrationstestmiljøet.

Tekniske oplysninger: Integrationstestmiljøet

Metadata og certifikater til brug for test i DevTest4-miljøet

• Eksempel på metadatafil (xml) til Devtest4-miljøet

  Inden I starter tests i DevTest4-miljøet, skal teknisk administrator uploade jeres tekniske data i XML format for it-systemet i NemLog-in Administration.

  Du kan hente et eksempel på en OIOSAML 3 metadata-fil på en test-it-systemudbyder.

  Bemærk, at:

  • private it-systemudbydere skal udlade 'PrivilegesIntermediate' og 'cprNumber' fra metadata.

  • vi anbefaler, at I anvender jeres eget certifikat. Læs afsnittet "Hent systemcertifikat til brug for integrationstest ovenfor".

  • I skal opdatere URL'er og EntityID anvendt, så det stemmer overens med det it-system, I gerne vil teste.

  Hent eksempel på OIOSAML3 metadata for test-tjenesteudbydere (xml)

• Metadatavalidatoren

  Teknisk administrator har i DevTest4-miljøet (pre-produktionsmiljøet) mulighed for at validere her: 

  NemLog-in DevTest4-miljøet - metadatavalidator

• Systemcertifikat, som skal indgå i metadata

  Testcertifikater bestilles nemmest i MitID Erhvervs DevTest4-miljø eller alternativt de tilhørende API'er.

  Det er meget vigtigt, at du udsteder certifikater til det miljø, som I foretager test i.

  DevTest4-miljøet (produktionsben): MitID Erhverv: Certifikatprofiler og certifikater

  DevTest4-miljøet (integrationstestben): MitID Erhverv: Certifikatprofiler og certifikater

  Følge denne vejledning fra trin 3, efter du er logget ind i det korrekte ben i MitID Erhverv DevTest4-miljøet, ved at følge et linkene ovenfor. Det er vigtigt, at du vælger "Systemcertifikat" i stedet for "Organisationscertifikat" under bestillingen.

  MitID-Erhverv.dk: Administrér organisationscertifikat: Bestil et organisationscertifikat

  Du kan alternativt vælge at hente et eksempel på et systemcertifikat, der dog ikke vil være tilknyttet din egen testorganisations CVR-nummer:

  OCES3 systemcertifikat (.p12)

  Adgangskode: c5,PnmF8;m4I

  Nøglefilerne, som genereres via MitID Erhverv, er i PKCS#12 format og krypteret med AES-algoritmen. Det kan give ældre software problemer med at læse dem. I givet fald kan man ompakke filerne til en anden krypteringsalgoritme ved brug af værktøjer såsom:

  • XCA
  • OpenSSL
  • andre værktøjer, som svarer til de 2 værktøjer ovenfor.

  Rodcertifikatet og udstedende certifikat til test kan hentes fra testcertifikatets .12-fil ved hjælp af relevant software til formålet.

  Spærrelister og OCSP services i OCES3 infrastrukturen udstilles ikke fra faste IP-adresser grundet DDOS-beskyttelsen af disse services. Det betyder, at eventuelle firewall regler for udgående trafik i jeres organisation skal defineres på host-navnet og ikke på IP-adresser.

• NemLog-in broker (IdP)

  Tilslutning af dit it-system til integrationstestmiljøet kræver, at dit system er konfigureret med teknisk information om integrationstestmiljøet. Denne information er samlet i en SAML metadata-fil.

  Metadata er defineret særskilt for de 3 forskellige OIOSAML-profiler i integrationstestmiljøet. Hvis dit it-system skal anvende OIOSAML 3, skal du anvende OIOSAML 3-metadata.

  Metadata

• OCES3 signeringscertifikat for opslagstjeneste (pem)

  Certifikatet anvendes til at signere svar på SOAP snitfladen (REST snitfladen anvender ikke certifikatet men baserer sig på TLS).

  Metadata

It-systemer eller brugere til brug for DevTest4-miljøet (pre-produktionsmiljøet)

• Testtjenester (it-systemer) udstilles i DevTest4milijøet (pre-produktionsmiljøet)

  Devtest4-miljøet udstiller følgende it-systemer til test, som kan anvendes i forskellige testscenarier:

  Test-tjeneste	OIOSAML-version	NameIDFormat	Privat/offentlig
  TU0	2.0.9*	X509Subject	Offentlig
  TU1	2.1.0	X509Subject	Offentlig
  TU2	2.1.0	Persistent Pseudonym	Offentlig
  TU3	3.0.2	Persistent	Offentlig
  TU4	3.0.2	Transient	Offentlig
  TU5	3.0.2	Persistent	Privat
  TU6	3.0.2	Transient	Privat

• Testorganisation: It-systemudbyder med fiktivt CVR-nummer

  I kan oprette en it-systemudbyder, som har et fiktivt CVR-nummer, til test.

  Når I har oprettet den, kan du bruge den i både produktions- og integrationstestben i DevTest4-miljøet (pre-produktionsmiljøet). 

  Testportalen: Opret testtjenesteudbyder i DevTest4-miljøet

  I kan finde en trin for trin vejledning til at oprette en it-systemudbyder til test her:

  Fiktivt CVR-nummer: Opret en it-systemudbyder til test

• Testorganisation: Brugerorganisation med fiktivt CVR-nummer

  I kan oprette en brugerorganisation, som har et fiktivt CVR-nummer, til test.

  Den kan fx bruges til test at:

  • oprette brugere i organisationen
  • udstede certifikater. 

  Når I har oprettet den, kan du bruge den i både produktions- og integrationstestben i DevTest4-miljøet (pre-produktionsmiljøet). 

  Testportalen: Opret test-brugerorgansiation i DevTest4-miljøet

  I kan finde en trin for trin vejledning til at oprette en it-systemudbyder til test her:

  Fiktivt CVR-nummer: Opret en brugerorganisation til test

• Testorganisation: It-systemudbyder eller brugerorganisation med selvvalgt navn og CVR-nummer

  I kan oprette en testorganisation med selvvalgt navn og CVR-nummer, dvs. jeres eget navn og CVR-nummer.

  Testorganisationen kan være både en it-systemudbyder eller brugerorganisation. 

  Når I har oprettet den, kan du bruge den i både produktions- og integrationstestben i DevTest4-miljøet (pre-produktionsmiljøet). 

  Testportalen: Opret test-brugerorgansiation i DevTest4-miljøet

  I kan finde en trin for trin-vejledning til at oprette en it-systemudbyder til test her:

  Fiktivt CVR-nummer: Opret en brugerorganisation til test

• Testbruger: Privat MitID bruger

  I kan oprette en privat MitID bruger til test i MitID Simulator. 

  Når I har oprettet testbrugeren, kan I bruge den i både integrationstest- og produktionsben i DevTest4-miljøet.

  MitID Simulator: Opret en testbruger (på engelsk)

  I kan finde en trin for trin vejledning til at oprette en testbruger her:

  Opret private MitID-brugere til test

   

• Testbruger: MitID Erhverv-bruger

  Når I har oprettet private MitID-brugere til test, kan I oprette MitID Erhverv-brugere med de netop oprettede MitID-brugere.

  Det er meget vigtigt at oprette en MitID Erhverv-bruger til test i det korrekte ben i DevTest4-miljøet (Pre-produktionsmiljøet). En MitID Erhverv-bruger til test kan ikke anvendes på tværs af benene i DevTest4-miljøet (Pre-produktionsmiljøet).

  MitID Erhverv i DevTest4-miljøet (pre-produktionsmiljøet) - produktionsben

  MitID Erhverv i DevTest4-miljøet (pre-produktionsmiljøet) - integrationstestben

  I kan finde en trin for trin vejledning til at oprette en MitID Erhverv-bruger til test her:

  Opret MitID Erhverv-brugere til test

Test af forskellige funktioner

• Integration med CPR, hvis I tester et it-system, hvorfra der udføres myndighedsopgave

  I produktionsmiljøet integrerer NemLog-in til det danske CPR-register. Data herfra anvendes blandt andet for at kunne oplyse for- og efternavne samt den nye CPRUUID attribut i SAML assertions. DevTest4-miljøet (pre-produktionsmiljøet) integrerer ikke til det danske CPR-register, men anvender i stedet et test-CPR-register. Indholdet i test-CPR-registreret oprettes, når der oprettes private MitID-brugere til test i MitID Simulator med CPR-numre.

  Når en privat testidentitet oprettes i MitID Simulator, registreres følgende oplysninger for identiteten i test-CPR-registeret:

  • CPR-nummer
  • Fornavn
  • Efternavn
  • CPRUUID.

  For CPRUUID anvendes samme UUID, som tildeles til MitID Simulator identiteten. Når du anvender MitID Simulator-brugergrænsefladen genererer MitID Simulator dette UUID. Hvis du ønsker selv at bestemme hvilket UUID, der anvendes, og dermed hvilket CPRUUID, der registreres i test-CPR-registeret, kan du anvende MitID Simulator API'et.

  Opret private MitID-brugere til test her:

  MitID simulator

  Opret private MitID-brugere til test via API:

  MitID simulator API

  Læs mere om, hvordan du opretter private MitID-brugere til test, i afsnittet 'Private MitID-brugere til test, som oprettes i MitID Simulatoren'

• Validering af CPR-nummer i et it-system, hvorfra der ikke udføres myndighedsopgave

  Private it-systemer er it-systemer, hvorfra der ikke udføres myndighedsopgaver.

  De kan ikke direkte få udleveret CPR-nummer attributten fra NemLog-ins broker som en del af SAML billetten i autentifikationssvaret.

  Hvis et privat it-system har brug for at kende en slutbrugers CPR-nummer, skal denne i stedet anvende en match-model, hvor slutbrugeren selv indtaster sit CPR-nummer i it-systemet, og hvor it-systemet herefter ved brug af et match-opslag kan verificere, om der er angivet det korrekte CPR-nummer for den autentificerede bruger.

  Der er følgende match-opslag til rådighed:

  SubjectMatchesCpr metoden i NemLog-ins opslagstjeneste tager som input et CPR-nummer og SAML Subject fra autentifikationen, og returnerer om der er match. Dette er den anbefalede metode til CPR-match.

  Begge disse metoder er understøttet i NemLog-ins testmiljøer såvel som produktion.

  Dokumentationen for NemLogins opslags- og match-tjenester

• Vis tjenesteudbyderens navn, når I er en broker

  Det er muligt at vise NemLog-in tjenesteudbyderens navn i MitID klienten, når brugeren logger på. Det kan øge gennemsigtigheden for slutbrugere omkring, hvilken tjeneste, der logges ind på i andet led, hvor sub-brokeren fremover skal medsende et navn på tjenesten, således NemLog-in kan vise dette i MitID klienten. Det betyder, at slutbrugere på loginsiden møder:

  Log på "Sub-brokerens navn" på vegne af: "Tjenesteudbyderens navn".

  Sub-brokere skal medsende den bagvedliggende tjenesteudbyders navn i deres SAML Autentifikationsforespørgsel i feltet ’ProviderName’ med en værdi beregnet som Base64(UTF8(<friendlyName>) og en maksimal længde på 100 tegn. Feltet må kun angives ved forespørgsler om autentifikation og ikke ved signering.

• Login uden sessiondannelse

  NemLog-ins broker danner normalt en session med den browser, hvormed brugeren autentificerer sig. Sessionen er grundlaget for single-sign-on (SSO) og single-log-out (SLO) for de applikationer, der udfører myndighedsopgaver.

  Det er ikke hensigtsmæssigt for alle it-systemer at etablere browsersessioner som sideeffekt af en autentifikation, herunder fx ved indrulleringsflows i native Apps, som anvender systembrowseren til interaktion med NemLog-in.

  Det er relevant at læse følgende afsnit i brugermanual til NemLog-in Administration.

  • 4.2.5: Indlæs testrapport
  • 7.19: Indlæs testrapport
  • 4.3.9 Håndtér en opgave (Godkendelse af testrapporten)
  • 5.2: Håndtér en opgave (Godkendelse af testrapporten)

  Brugermanual til NemLog-in Administration (pdf)

Hvis I oplever fejl under test i DevTest4-miljøet (pre-produktionsmiljøet)

• Sådan søger du fejl, som I oplever under test i DevTest4-miljøet

  Du kan søge fejl ved at få adgang til systemets log via LogViewer. Der er dog kun adgang til log for integrationstestsben i DevTest4-miljøet.

  NemLog-in DevTest4-miljø - LogViewer

  Læs vejledningen nedenfor:

  Vejledning om LogVieweren (på engelsk, pdf)