Metadata og certifikater til brug for integrationstest
-
Inden I starter integrationstest, 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:
-
'PrivilegesIntermediate' og 'cprNumber' er udkommenteret for organisationer, der ikke udfører myndighedsopgaver, i eksemplet nedenfor. Hvis I tester it-systemer, hvorfra der udføres myndighedsopgaver, skal I tilføje dem igen.
-
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.
En myndighedsopgave er som udgangspunkt en opgave eller funktion, der er tildelt og udført af en offentlig myndighed eller et offentligretligt organ. En myndighedsopgave kan omfatte en bred vifte af aktiviteter, såsom regulering, tilsyn, servicelevering og andre opgaver, der er knyttet til organisationens rolle. Det er den enkelte offentlige myndighed eller offentligretlige organ, der er ansvarlig for at vurdere, om den digitale selvbetjeningsløsning anvendes i forbindelse med udførelse af en myndighedsopgave.
-
-
Teknisk administrator har i integrationstestmiljøet mulighed for at validere metadata her:
-
Testcertifikater bestilles nemmest i MitID Erhvervs integrationstestmiljø eller alternativt de tilhørende API'er.
MitID Erhverv Integrationstestmiljøet: Certifikatprofiler og certifikater
Følge denne vejledning fra trin 3, efter du er logget ind i MitID Erhverv integrationstestmiljøet, ved at følge linket 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:
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.
-
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 2 forskellige OIOSAML-profiler i integrationstestmiljøet. Hvis dit it-system skal anvende OIOSAML 3, skal du anvende OIOSAML 3-metadata.
-
Certifikatet anvendes til at signere svar på SOAP snitfladen (REST snitfladen anvender ikke certifikatet men baserer sig på TLS).
It-systemer eller brugere til brug for integrationstest
-
Integrationstestmiljøet udstiller et antal testtjenester, 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 *OIOSAML 2.0.9 er ikke understøttet i integrationstestmiljøet, men denne testtjeneste forespørger en eller flere af de udfasede attributter i metadata.
-
NemLog-in indeholder en MitID Simulator, der kan oprette MitID Privat brugere, som kan logge ind via fanen "Test login" i NemLog-in ved at bruge brugernavn og password.
Angiv:
- brugernavn
- password
- fornavn, som er fiktivt
- efternavn, som er fiktivt
- fiktivt CPR-nummer
- administrator-e-mailadresse.
Fornavn, efternavn og CPR-nummer skal være fiktive, da integrationstestmiljøet er et testmiljø.
I kan angive jeres egen e-mailadresse som administrator-e-mailadresse, hvis der senere skal ændres på testidentitetens data.
- Test af login med privat MitID: Sæt flueben i "Private MitID"-boksen.
- Test af erhvervslogin: Undlad at sætte flueben i "Private MitID"-boksen.
Når alt nødvendig er udfyldt, vælg "Create identity".
Du kan også oprette testbrugere via MitID Test Tool. De brugere, som er oprettet i MitID Test tool, kan logge ind via fanen "MitID" fanen i NemLog-in via brug af simuleret to-faktor login. Læs nærmere om denne type testbrugere i næste menupunkt.
-
Ved hjælp af MitID Test Tool kan I oprette og vedligeholde MitID testbrugere, som kan logge ind via fanen 'MitID'i NemLog-in via simuleret to-faktor login.
Dette er et alternativ til at oprette testbrugere i MitID Simulatoren. Når I logger ind med testbrugere fra MitID Simulatoren, bruger I fanen "Test login".
MitID Test ToolNår du tester med privat MitID, er det også nødvendigt, at testbrugeren er oprettet i integrationsmiljøets test-CPR-register. For at forberede en test med MitID, skal I:
- oprette testbrugere i MitID Test Tool
- oprette en testbruger, som har den oprettede MitID's navn og CPR-nummer, i MitID Simulator. Husk at sætte flueben i ”Private MitID”-boksen.
NemLog-in stiller følgende testbrugere, som er oprettet i MitID Test Tool, til rådighed, hvis I ikke ønsker at oprette egne testbrugere.
Brugernavne: Ellie999, Sabastian555 og Stig777
Password (gælder for alle 3 brugernavne): Test1234
Vejledning til anvendelse af testbrugere, der er oprettet i MitID Test Tool (pdf)
-
I skal først oprette en testbrugerorganisation i MitID Erhvervs integrationstestmiljø. I kan følge vejledningen her:
Når testorganisationen er oprettet i integrationstestmiljøet, kan I oprette testbrugere, som I kan anvende. I kan oprette brugere her:
MitID Erhverv integrationstestmiljø
I kan bruge denne vejledning til at oprette brugere, men vejledningen er skrevet til produktionsmiljøet. Husk at logge ind på integrationstestmiljøet i stedet for produktionsmiljøet.
MitID-Erhverv.dk: Opret, redigér, slet eller masseopret brugere: Opret nye brugere
Herefter kan de oprettede testbrugere logge på (og signere) hos tjenesteudbydere tilsluttet NemLog-ins integrationstestmiljø. Det er også muligt at anvende de testtjenester, som allerede findes oprettet i integrationstestmiljøet, som fx Digitaliseringsstyrelsen Internal Test SP OIOSAML-3.0. Dette er fx nyttigt til test af single sign-on (SSO) med din egen testtjeneste.
-
I skal først oprette en testorganisation på testportalen:
Når testorganisationen er oprettet i integrationstestmiljøet, kan I oprette testbrugere, som I kan anvende. I kan oprette brugere her:
MitID Erhverv integrationstestmiljø
I kan bruge denne vejledning til at oprette brugere, men vejledningen er skrevet til produktionsmiljøet. Husk at logge ind på integrationstestmiljøet i stedet for produktionsmiljøet.
MitID-Erhverv.dk: Opret, redigér, slet eller masseopret brugere: Opret nye brugere
Herefter kan de oprettede testbrugere logge på (og signere) hos tjenesteudbydere tilsluttet NemLog-ins integrationstestmiljø. Det er også muligt at anvende de testtjenester, som allerede findes oprettet i integrationstestmiljøet, som fx Digitaliseringsstyrelsen Internal Test SP OIOSAML-3.0. Dette er fx nyttigt til test af single sign-on (SSO) med din egen testtjeneste.
Test af forskellige funktioner
-
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.
Integrationstestmiljø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 test-identiteter 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.
-
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.
-
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.
-
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)
-
Det er også muligt at teste NemLog-in Attribute Service i integrationstestmiljøet.
Metadata for Attribute Query Service samt Security Token Service på siden med metada
-
Der findes særlige sider om, hvordan STS integreres.
Hvis I oplever fejl under integrationstesten
-
Brug denne vejledning for at søge fejl, som I oplever under integrationstesten:
Hjælp til fejlsøgning af din tjeneste (pdf)
Det er også muligt at tilgå loggen. Dette sker via LogVieweren:
NemLog-in Testmiljø - LogViewer
Læs vejledningen nedenfor: