Page History

...

De viste services i figuren udenfor er uddybet i tabellen nedenfor. ** CHG: Hvilken klassifikation benyttes til 'Sikkerhedsniveau' her? DGWS og har sin egen klassifikation, OIOSAML anvender NIST. Forvirrer kolonnen ikke mere end den gavner? Skal vi ikke droppe den? **

Anvendere af STS skal sættes op og tilføjes til STS konfiguration, inden de kan begynde at anvende udstedelses- og omvekslingsservices ** CHG: Nej, kun de nyere STS-snitflader kræver klient-whitelisting. Det bør angives på snitflade-niveau hvilke der gør - måske kunne man jo erstatte 'Sikkerhedsniveau' kolonnen med 'Kræver whitelisting' eller lignende i ovenstående? **. Anvendere identificeres vha CVR nummer, som er inkluderet i OCES certifikater. Når en anvender autentificerer sig overfor STS vha et OCES certifikat, så konsulterer STS sin konfiguration og tjekker, om det pågældende CVR nummer er konfigureret, og om det f.eks. har adgang til det specificerede intended audience. De specifikke valideringer og regler gennemgåes i afsnitene nedenfor vedr DGWS, medarbejderomvekslinger og borgeromvekslinger.

...

1. Anvendersystemet bygger et SOSI Idkort indeholdende informationer om brugeren/systemet og signerer det med et certifikat (VOCES/FOCES/MOCES certifikat udstedt af CA rodcertifikatet i den fællesoffentlige føderation).

2. SOSI Idkortet sendes i udstedelsesforespørgsel til STS, der validerer signaturen. Ydermere tjekkes det om certifikatet er spærret (revokeret) for anvendelse. STS konsulterer sin konfiguration for at tjekke, at det konkrete CVR nummer i certifikatet er whitelistet til at kunne trække SOSI Idkort. **CHG: Nej, der er ingen whitelist check længere (medmindre det blev genindført igen )**udstedelsesforespørgsel til STS, der validerer signaturen. Ydermere tjekkes det om certifikatet er spærret (revokeret) for anvendelse.

3. Korrektheden af attributterne i anvendersystemets SOSI Idkort verificeres af STS. En del af attributterne i SOSI Idkortet vil kunne valideres op i mod det anvendte certifikat. I tilfældet med Bruger Idkort (signeret med MOCES certifikat) vil en del af attributterne være at betragte som claims. Disse attributter valideres på følgende måde (se i øvrigt overblikket over STS ovenfor):

   1. CPR nummer: RID-CPR servicen hos Nets anvendes til at verificere, om et givent CPR nummer hører sammen med et givent RID i det anvendte MOCES certifikat.

   2. Autorisationsnummer: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at det angivne autorisationsnummer hører sammen med det angivne CPR nummer.

   3. Uddannelseskode: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at den angivne uddannelseskode hører sammen med det angivne CPR nummer.

   4. National rolle: Hvis der er angivet en national rolle, så tjekker STS op i mod sin kopi af stamdata, at den pågældende bruger er i besiddelse af den angivne rolle. Hvis en anvender ikke har angivet en national rolle i claim, men den pågældende medarbejder er i besiddelse af netop én nationale rolle vil denne automatisk inkluderes i det udstedet SOSI Idkort. **CHG: Der er en whiteliste whitelist for trustede CVR-organisationer, som selv administrere nationale roller lokalt. For disse trustes den nationale rolle der er claimet - dvs. ingen opslag i SDM**stamdata.

4. STS opbygger et nyt SOSI Idkort med de samme informationer som det SOSI Idkort, der udgjorde forspørgslen fra anvenderen. Dette Idkort signeres med STS'ens eget certifikat.
5. STS sender det nye SOSI Idkort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
6. 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.
7. NSP-komponenten verificerer at SOSI Idkort er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat **CHG: Hver STS har sit eget certifikat. Så det er 'listen' eller nærmere definitionen af familen af føderationcertifikater der er kendt ** er kendt SOSI STS'ernes certifikater er kendte af alle komponenter i føderationen.

...

1. Anvendersystemet er i besiddelse af et Bruger SOSI Idkort for en given medarbejder. Dette Idkort sendes i en forespørgsel til STS på omvekslingsendpointet. Som en den af forespørgslen angives et audience (dvs en tiltænkt anvendelse af den udstedte billet).
2. STS validerer det indgående SOSI Idkort dvs at det pågældende kort ikke er udløbet, at det er udstedt af en troværdig udsteder (i praksis STS selv) samt, at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). Derudover tjekkes det ønskede audience op i mod STS'ens egen konfiguration. STS arbejder med et konfigureret sæt af lovlige audiences, og det forespurgte audience skal være blandt disse.
3. Hvis forespørgslen er i orden danner STS en OIO SAML billet og underskriver den med sit eget certifikat . ** CHG: Og og krypterer det til den angivne audience! **.
4. Den udstedte OIO SAML billet sendes tilbage til anvendersystemet
5. Anvendersystemet kan nu anvende den udstedte billet til at aktivere services i NemLogin føderationen. ** CHG: Tja - den kan bruges til at tilgå/opstarte OIOSAML-baserede webløsninger som understøtter 'SAML unsolicited response' flowet og truster SOSI-STS ** . I det viste eksempel nedenfor giver den udstedte billet adgang for medarbejderen til sundhed.dk ved hjælp af en sikker browser opstart.

...

1. Anvendersystemet er i besiddelse af en OIO SAML billet eller en OIOSAML-baseret bootstraptoken for en given medarbejder (i praksis udstedt af NemLogin **CHG: Nej, bootstraptokens vil også være udstedt at , SEB eller andre af SOSI STS trustede lokale IdP'er eller SEB **/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 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) **CHG: Lidt upræcis. I OIOSAML2SOSI angives oplsyningerne i en separate SAML billet (HealthcareContextToken hedder det vistnok), men i BST2SOSI  ligger oplsyninger som WS-Trust cliams.**
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 **CHG: Nej, bootstraptokens vil også være udstedt at , SEB eller andre af SOSI STS trustede lokale IdP'er eller SEB **/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 **CHG: Igen - BST2SOSI anvender WS-Trust claims. Måske var det ikke nogen god ide at blande OIOSAML2SOSI og BST2SOSI sammen .... **(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.

...

Omveksling til OIO SAML sikkerhedsbillet minder i formål og flow om det, som blev beskrevet under Medarbejderomveksling. Der henvises til (slettes) STS - Borger-billetomveksling for yderligere detaljer. Forskellen i borgeromvekslingen til OIO SAML er at inputbilletten til omvekslingen er et JWT. JWT tokenet skal være udstedt af en identity provider, som STS'en stoler på f.eks. loginbrokeren, der anvendes i forbindelse med MinLæge app'en. **CHG: Lidt for kort beskrivelse - tilføj at billetten krypteres til den   Den udstedte billet krypteres til det ønskede audience og er tiltænkt anvendt til SBO **Sikker Browser Opstart (SBO).

Den anden type af borgeromvekslinger veksler JWT eller bootstrap token til OIO IDWS sikkerhedsbillet. Formålet med denne omveksling er at gøre det muligt for anvendere at tilgå borgerrettede IDWS services på National Service Platform f.eks. MinSpærring, Dokumentdelingsservice (DDS) eller Minlog2. **CHG: Tilføj lidt om at der kan claimes fuldmagter og at audience skal angives, dvs. IDWS billetten er audience-specifik i modsætning til SOSI idkort **

Borgeromvekslingerne understøtter også, at der angives et claim med en anden borgers CPR nummer for fuldmagtsunderstøttelse (se nedenfor).

Den udstedte OIO IDWS sikkerhedsbillet indeholder altid et audience, der angiver, hvordan billetten er tænkt anvendt.

Anvendernes interaktion med STS i forbindelse med borgeromveksling til OIO IDWS sikkerhedsbillet :

...

1. Anvendersystemet er i besiddelse af en JWT eller bootstrap token for en borger (i praksis udstedt af NemLogin eller 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 **CHG: Der mangler ordet 'fuldmagt' i den sætning **. 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. **CHG: Der kun fuldmagtsprivilegier der er givet for den ønskede audience der kommer i billetten, ikke alle privilegier **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-komponenter **CHG: Ikke 'komponenter' - kun den service 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. Den offentlige nøgle for STS'ens certifikat **CHG: ' Familie af føderationscertifikater ' - se kommentar længere oppe ** for SOSI STS er kendt af alle komponenter services i føderationen.

Der henvises til STS - Guide til anvendere: Borgeromvekslinger for yderligere detaljer.

...

• Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen). **CHG: Lidt uklart hvad der egentlig menes her. Hvilke type OCES certifikat og til hvad skal det bruges? Og så kræver SOSI2OIOSAML ikke noget certifikat **
  
  • Der kan findes test OCES certifikater til at komme i gang med her.
  • Anvendere kan desuden kontakte NETS med henblik på at få en tjenesteudbyderaftale, hvilket vil gøre det muligt at få udstedt egne OCES certifikater til både test og produktion. **CHG: Tilføj et link**
• Anvenderen skal oprettes som anvender til STS. **CHG: Hvad indebærer det? Jeg synes der bør skelnes mellem hvad der er teknik (den her vejledning) og hvad der er aftaler (og link til det)** Dette gøres i praksis ved at rette henvendelse til servicedesk på nspop.dk. Henvendelsen skal indeholde oplysninger om:
  • Det certifikat/de certifikater, som anvenderen ønsker at benytte i forbindelse med brugen af STS. **CHG: Ikke altid - se nedenunder (og længere oppe). Og hvordan skal 'benytte i forbindelse med' tolkes? Menes der whitelisting her?**
  • Angivelse af hvilke (hvis nogen) omvekslingsservices, der ønsker benyttet. ***CHG: Kun hvis der skal omveksles **
  • Ekstra informationer (i forbindelse med de enkelte STS services) inkluderes. Brug tabellen nedenfor.

...