Page History

...

...

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.

...

Anvendernes interaktion med STS i forbindelse med udstedelse af SOSI Idkort er fælles i begge tilfælde: **CHG: Diagrammet vises ikke - jeg får "You do not have permission to view this diagram." **

...

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 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, 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 **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:(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.

...

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

Adgang til STS

**CHG: Dette afsnit fremstår noget uklar. Visse konfigurations-elementer skal slet ikke komme fra "anvenderne", men af anden part (fx er det jo ikke et LPS system der benytter BST2SOSI med et BST fra SEB der skal angive SEBs certifikat i tilslutningen). Der skal derfor i nedenstående skelnes skarpt hvordan service-anvenderne/klienterne, tokenudstedere (IdP'er) og service-udbydere opsættes i STS. **

**CHG: Her mangler noget om evt. whitelisting **

Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads:

Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads:

• Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen). 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**til både test og produktion.
• Anvenderen skal oprettes som anvender til STS. 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.
  • Ekstra informationer (i forbindelse med de enkelte STS services) inkluderes. Brug tabellen nedenfor.