Page History

...

...

STS har også integration til de tre services PID-CPR, RID-CPR og UUID2CPR udbudt af Nets. Denne integration muliggør verifikation af et påstået (claim) CPR nummers sammenhæng med PID, RID eller UUID. Disse egenskaber er f.eks tilstede i MOCES OCES certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLog-inSEB. Derudover validerer STS anvendte OCES certifikater. Alle OCES-certifikater udstedes af Nets DanID, der varetager denne opgave for Digitaliseringsstyrelsen. OCES certifikater kan tilbagekaldes (revokeres), hvis f.eks. den private nøgle bliver kompromiteret. Tilbagekaldte certifikater publiceres på revokeringslister (CRL = Certificate Revocation Lists). Revokeringslisterne hentes løbende og opbevares i en database (CRL database på tegningen). Oplysningerne vedrørende revokering tjekkes i forbindelse med kald af STS udstedelses- eller omvekslingsservices. Således kan revokerede/spærrede certifikater ikke anvendes til at få udstedt/vekslet sikkerhedsbilletter.

...

• System Idkort: Udstedes på vegne af en "anvenderservice". Kravene til autentifikation overfor STS ved udstedelse er certifikater af typen VOCES eller FOCES.
• Bruger Idkort: Udstedes på vegne af en medarbejder (enten med eller uden sundhedsfaglig autorisation). Kravene til autentifikation overfor STS ved udstedelse er certifikater af typen MOCESOCES.

Anvendernes interaktion med STS i forbindelse med udstedelse af SOSI Idkort er fælles i begge tilfælde:

...

• Omveksling fra Bruger SOSI Idkort til OIO SAML billet
• Omveksling fra OIO SAML billet til Bruger SOSI Idkort
• Omveksling fra OIO fra OIO Saml bootstrap token til Bruger til Bruger SOSI Idkort (en videreudvikling af SOSI sikkerhedsinfrastrukturen så den understøtter MitID, Nemlog-in3 og MitID og OCES3)

Som det blev beskrevet i forgående afsnit er formålet med at anskaffe et Bruger SOSI Idkort at få adgang til en eller flere NSP DGWS Services.

Formålet med at fremskaffe en OIO SAML billet vil typisk være at foretage kald i NemLogin føderationenføderation, som kræver OIO SAML billet. Dette kunne f.eks. være at opnå en "sikker browser opstart" for en sundhedsfaglig bruger til sundhed.dk.

...

1. Anvendersystemet er i besiddelse af en OIO SAML billet eller en OIOSAML-baseret bootstraptoken for en given medarbejder (i praksis udstedt af NemLogin, SEB eller andre af SOSI STS trustede lokale IdP'er/udstedere). Denne sendes i en forespørgsel til STS på omvekslingsendpointet. Der kan være brug for at det udstedte SOSI Idkort er beriget med flere oplysninger, end dem, der er til stede i den af NemLogin udstedte den udstedte OIO SAML billet eller bootstraptoken. Disse specificeres af anvendersystemet i en af dette system defineret SAML billet (i praksis kan denne SAML billet betragtes som en holder for anvendersystemets claims) eller angives som WS Trust claims.
2. STS validerer den indgående billet (den grønne i diagrammet) dvs at den udstedte billet ikke er udløbet, at det er udstedt af en troværdig udsteder (i praksis udstedt af NemLogin, SEB eller andre af SOSI STS trustede lokale IdP'er/udstedere) samt at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). De supplerende oplysninger (claims) defineret af den af anvendersystemet udstedte SAML billet eller medstendte WS Trust claims (den røde i diagrammet) valideres af STS på følgende måde:
   1. Hvis anvendersystemet har definerer et CPR nummer som et claim valideres dette. Det gøres ud fra RID oplysninger i billetten (vha RID-CPR service) hvis de er til stede, ellers ud fra det medsendte medarbejder uuid (vha UUID2CPR service).
   2. Hvis anvendersystemet ikke har defineret et CPR nummer, slås det op med RID-CPR servicen eller UUID2CPR servicen.
   3. Hvis anvendersystemet har claimet en national rolle, så valideres denne.
      1. Hvis BST tokenet har indlejret en liste af nationale roller, valideres i forhold til denne.
      2. Findes rollen ikke i indlejret liste, valideres i forhold til de registrerede stamdata (roller i SEB-registeret).
   4. Hvis anvendersystemet har claimet et autorisationsnummer for medarbejderen, så valideres dette op i mod autorisationsregisteret.
   5. Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen identificeret i den indkommende billet har netop én autorisation i autorisationsregisteret, vil denne automatisk indsættes i det udstedte SOSI Idkort.
   6. Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen har netop én national rolle (i enten indlejret liste eller SEB-registeret) og ingen autorisationer, vil denne rolle automatisk indsættes i det udstedte SOSI Idkort.
   7. Hvis anvendersystemet har claimet en lokal (ikke national) rolle, så kopieres denne til det udstedte SOSI Idkort uden yderligere validering.
3. Hvis forespørgslen er i orden danner STS et SOSI Idkort med oplysninger fra hhv OIO SAML billetten og claims og underskriver dette med sit eget certifikat.
4. Det udstedte SOSI Idkort sendes tilbage til anvendersystemet.
5. Anvendersystemet anvender det nye SOSI Idkort i forespørgelser mod NSP-komponenter. Bemærk at et SOSI Idkort kan anvendes til flere forespørgelser mod flere forskellige services, så længe det endnu ikke er udløbet.
6. NSP-komponenten verificerer at SOSI Idkort er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat er kendt af alle komponenter i føderationen.

...

1. Anvendersystemet er i besiddelse af en JWT eller bootstrap token for en borger (i praksis udstedt af NemLogin eller en af en loginbroker, fx den der anvendes i forbindelse med MinLæge app'en). Denne OIO billet sendes i en forespørgsel til STS på omvekslingsendpointet.
2. Der kan være brug for at det udstedte IDWS token er beriget med flere oplysninger, end dem, der er til stede i JWT eller bootstrap tokenet. Disse specificeres af anvendersystemet som claims i forespørgslen. Følgende claims er relevante:
   
   1. CPR nummer for borgeren
   2. CPR nummer for anden borger, hvis billetten skal bruges til at tilgå  andre borgeres oplysninger. Dette kræver, at der er fuldmagt til dette.
3. STS validerer det indgående JWT/bootstrap billet dvs tjecker at den medsendte billet ikke er udløbet, at det er udstedt af en troværdig udsteder samt at ingen af de anvendte certifikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). De supplerende oplysninger (claims) som er defineret af anvendersystemet valideres af STS på følgende måde:
   1. Hvis anvendersystemet definerer et CPR nummer som et claim valideres dette udfra PID (vha CPR-PID service) eller CPR oplysninger i input billetten.
   2. Hvis anvendersystemet har claimet et andet CPR nummer (dvs identiteten på den borger b, som borgeren i pkt a forsøger at tilgå), så vil STS tilgå fuldmagtsregisteret og finde de fuldmagter, der er givet fra borger b til borger a i forhold til det claimede audience. Listen af disse vil være inkluderet i IDWS tokenet, og det er op til den modtagende service at validere disse.
   3. Det er obligatorisk at angive et audience for det IDWS token, som ønskes udstedt. Audience angiver, hvilken service, som man har tiltænkt at bruge tokenet mod. STS validerer det ønskede audience op i mod sin konfiguration (liste af lovlige audiences). For veksling af JWT tokens bliver det tjekket at det indgående token er i besiddelse af nødvendige scopes (en mapning fra JWT scopes til audiences er konfigureret for STS).
4. Det udstedte IDWS token sendes tilbage til anvendersystemet.
5. Anvendersystemet anvender det nye IDWS token i forespørgelser mod NSP-service, som IDWS tokenet er udstedt til. Bemærk at et IDWS token kan anvendes til flere forespørgelser, så længe det endnu ikke er udløbet. Dog er det begrænset, hvilke services det udstedte token kan anvendes til (audience).
6. NSP-komponenten verificerer at IDWS tokenet er signeret af et føderationens certifikat. Familie af føderationscertifikater for SOSI STS er kendt af alle services i føderationen.

...