...

STS er i dette dokument synonymt med en konkret NSP service - SOSI STS. Men STS kan også opfattes som et koncept: I denne sammenhæng står STS for Secure Token Server Security Token Service (se f.eks. https://en.wikipedia.org/wiki/Security_token_service).

Dette er et kendt begreb indenfor IT sikkerhedsarkitekturer og beskriver en service, hvis formål er

• Udstedelse
• Validering og
• Fornyelse/omveksling af sikkerhedsbilletter.

Ideen med en Secure Security Token Server Service er, at der kan opnåes en afkobling mellem serviceanvender og serviceudbyder som illustreret i figuren nedenfor.

Som figuren illustrer, så behøver en serviceudbyder og serviceanvenderen ikke at etablere et kendskab hinanden, inden serviceanvenderen kan gøre brug af serviceudbyderen. Det, at en serviceanvender i kaldøjeblikket er i besiddelse af en sikkerhedsbillet udstedt og signeret af en Secure Security Token ServerService, som serviceudbyderen stoler på (trust) er nok til, at serviceudbyderen kan være sikker på, at det er ok at svare på et servicekald. Serviceudbyderen stoler således på serviceanvenderen, fordi serviceudbyderen stoler på Secure Security Token Server Service (se pil nr. 4 i tegningen ovenfor).

Serviceanvenderen skal identificerer autentificere sig overfor Secure Security Token Server Service for at få udstedt sin sikkerhedsbillet. Secure Security Token Server Service skal således enten kende serviceanvenderen direkte eller præsenteres for en sikkerhedsbillet, der identificerer serviceanvenderen, og som er udstedt af troværdig tredjepart (en anden Secure Security Token Server Service eller Identity Provider), som Secure Security Token Server Service stoler på.

Det er muligt, at serviceanvenderen kan have behov for, at sikkerhedsbilletten indeholder særlige oplysninger, som serviceanvenderen ønsker, at serviceudbyderen skal vide f.eks. for at få adgang til specielle services/data hos serviceudbyderen. Serviceanvenderen kan bede om, at disse oplysninger inkluderes ved at medsende ekstra påstande (claims) i sin forespørgsel til Secure Security Token Server Service (pil nr. 1 i tegningen ovenfor).

I visse tilfælde kan en Secure Security Token Server Service kræve, at en serviceanvender specificerer, hvad sikkerhedsbilletten skal anvendes til (intended audience). Det er op til Secure Security Token Server Service at beslutte, om de medstende medsendte claims og/eller intended audience kan opfyldes. Secure Security Token Server Service sammensætter sikkerhedsbilletten udfra serviceanvenderens identitet, eventuelle ønsker fra serviceanvender (claims+intended audience) samt prædefinerede konfigurationer. Nogle oplysninger kan Secure Security Token Server Service selv være i besiddelse af, men det er også muligt, at Secure Security Token Server Service betjener sig af en eller flere eksterne services til at slå ekstra oplysninger op om serviceanvenderen eller at verificere oplysninger eller claims (pil nr 2 i tegningen ovenfor).

Secure Security Token Server Service sammensætter sikkerhedsbilletten og returnerer denne til kalderen (pil nr. 3 i tegningen ovenfor).

...

• Signatur: En sikkerhedsbillet skal være signeret af den udstedende Secure Security Token ServerService. Signaturen kan valideres hos serviceudbyderen ved at sammenholde den med Secure Security Token Servers Services offentlige nøgle (trust).
• Udstedelses- og/eller udløbstidspunkt: Sikkerhedsbilletter vil være gyldige i fast defineret tidsperiode. Hvis en serviceanvender ønsker at fortsætte med at betjene sig af serviceudbyderen efter en sikkerhedsbillets udløb, må der udstedes en ny sikkerhedsbillet.
• Sikkerhedsniveau: Det kan give mening at inkludere en indikation af under hvilke omstændigheder en sikkerhedsbillet er blevet tilvejebragt. Er der f.eks. anvendt brugernavn+password eller en 2-faktor login mekanisme til dette. Digitaliseringsstyrelsens NSIS er et eksempel på en sådan klassifikation.

...

• Navn
• Officielle id'er (f.eks. cprnummer, autorisationsid)
• Organisatoriske tilhørsfohold
• Roller
• Fuldmagtsoplysninger

Det er vigtigt at forstå, at det alene er service-udbyderens ansvar at foretage adgangsstyring i forhold til den udbudte service og de adgangskritierier, som denne kræver. Beslutning om adgang/ikke-adgang træffes altså udelukkende af service-udbyderen. Grundlaget for denne beslutning er sikkerhedsbilletten og dennes indhold (attributter) og service-udbyderens trust til den udstedende Security Token Service.

STS på National Service Platform (NSP)

Der findes i dag en række forretningsservice forretnings- og støtteservices på NSP. Disse services dækker forskellige formål - fra datadeling via Dokumentdelingsservice (DDS)  til verifikation af behandlingsrelation via Behandlingsrelationsservice (BRS).logning via MinLog2. 

Selvom formålene for NSP services er forskellige, så har de en række fællestræk f.eks. i forhold til autentificeringautentifikation. Det betyder dog ikke at alle NSP services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er der en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation for gyldighed i de konkrete NSP services.

På NSP hedder servicen, der anvendes som Security Token Service (, SOSI-STS).

Der er i skrivende stund to aktuelle sikkerhedsprotokoller i spil på NSP:

...

• SOSI Idkort (medarbejder og systemadgang til DGWS beskyttede services)
• OIO IDWS billet (borgerbilletter til f.eks. adgang til OIO IDWS beskyttede services)
• OIO SAML billet (medarbejderbillet eller borgerbillet feks. til sikker sessionsoverdragelse (SSO)/sikker browseropstart til løsningerne sundhed.dk eller forløbsplaner.dk)

...

Som beskrevet i afsnittet ovenfor, så skal en potentiel anvender til en NSP service først integrere med STS og identificere autentificere sig overfor denne med henblik på at få udstedt en til formålet passende sikkerhedsbillet.

...

• Medarbejdercertifikat (MOCES): Udstedes til en medarbejder af en virksomhed og anvendes til autentifikation af den person, der udfører en handling ifm. sin ansættelse i virksomheden.
• Virksomhedscertifikat (VOCES): Udstedes til virksomheder og anvendes til autentifikation af selve virksomheden.
• Funktionscertifikat (FOCES): Udstedes til virksomheder og bruges til autentifikation af en applikation, en enhed, en proces eller en service.

Som nævnt tidligertidligere, så er de væsentligste opgaver for STS at udstede, validere og forny/ omveksle sikkerhedsbilletter.

...

• Hvilke snitflader udbydes (herunder en inddeling af snitfladerne i overordnede områder)?
• Hvilke andre systemer integrerer STS med, og hvad er formålet med disse integrationer?

Efterfølgende vil vi beskrive beskrives de tre overordnede anvendelsesområder, som er understøttet af STS:

...

De viste services i figuren udenfor er uddybet i tabellen nedenfor.

Anvendere af STS skal sættes op og tilføjes til STS konfiguration, inden de kan begynde at anvende udstedelses- og omvekslingsservices. 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 De enkelte services kan kræve speciel opsætning af STS (f.eks. whitelisting af anvenders CVR nummer). De specifikke krav og opsætninger gennemgåes i afsnitene nedenfor vedr DGWS, medarbejderomvekslinger og borgeromvekslinger.

STS indeholder synkroniseret data fra følgende registre:

• Autorisationsregisteret: Angiver sammenhæng mellem CPR numre på sundhedspersoner samt disses autorisationsid(er). Muliggør berigelse af sikkerhedsbilletter med autorisationsid for sundhedspersoner.
• Nationale roller: STS synkroniserer med faste intervaller de i SEB administrerede roller. Denne synkronisering muliggør berigelse af sikkerhedsbilletter med nationale roller for medarbejdere (med/uden sundhedsfaglig autorisation)

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 OCES certifikater og OIO Saml sikkerhedsbilletter udstedt af SEB. Derudover validerer STS anvendte OCES certifikater. Alle OCES-certifikater udstedes af Nets, der varetager denne opgave for Digitaliseringsstyrelsen. OCES certifikater kan tilbagekaldes (revokeres), hvis f.eks. Som nævnt i de forgående afsnit, så identificerer anvendere sig overfor STS ved hjælp af 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.

STS indeholder synkroniseret data fra følgende registre:

• Autorisationsregisteret: Angiver sammenhæng mellem CPR numre på sundhedspersoner samt disses autorisationsid(er). Muliggør berigelse af sikkerhedsbilletter med autorisationsid for sundhedspersoner.
• Nationale roller: STS synkroniserer med faste intervaller de i SEB administrerede roller. Denne synkronisering muliggør berigelse af sikkerhedsbilletter med nationale roller for medarbejdere (med/uden lægefaglig autorisation)

STS har også integration til de to services PID-CPR og RID-CPR udbudt af Nets. Denne integration muliggør verifikation af et påstået (claim) CPR nummers sammenhæng med PID henholdsvis RID. Disse egenskaber er f.eks tilstede i MOCES certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLogin.

Digitaliseringsstyrelsens fuldmagtsregister giver borgere i Danmark mulighed for at tildele fuldmagt til venner og pårørende til at opnå dataadgang. Borgere kan vedligeholde deres fuldmagtstildelinger via portalen http://borger.dk. I forbindelse med borgerbilletter har STS via fuldmagtsregisteret mulighed for at tjekke claims om fuldmagt, som angives i forbindelse med omveksling af borgerbilletter.

Anvendelseområder

De ovenfor nævnte anvendelsesområder uddybes i følgende afsnit. Hvert område beskrives kort med hensyn til overordnet formål. Dernæst skitseres flowet indenfor det pågældende område. Hver beskrivelse afsluttes med link til uddybende dokumentation.

Anvendelse: DGWS

STS indeholder to services til udstedelse af SOSI Idkort. Det overordnede formål er, at udstede SOSI Idkort der gør det muligt for anvendere at tilgå DGWS services på National Service Platform f.eks. MinSpærring, DRS eller andre Forretningsservices.

Digitaliseringsstyrelsens fuldmagtsregister giver borgere i Danmark mulighed for at tildele fuldmagt til venner og pårørende til at opnå dataadgang. Borgere kan vedligeholde deres fuldmagtstildelinger via portalen http://borger.dk. I forbindelse med borgerbilletter har STS via fuldmagtsregisteret mulighed for at tjekke claims om fuldmagt, som angives i forbindelse med omveksling af borgerbilletter.

Anvendelseområder

De ovenfor nævnte anvendelsesområder uddybes i følgende afsnit. Hvert område beskrives kort med hensyn til overordnet formål. Dernæst skitseres flowet indenfor det pågældende område. Hver beskrivelse afsluttes med link til uddybende dokumentation.

Anvendelse: DGWS

STS indeholder to services til udstedelse af SOSI Idkort. Det overordnede formål er, at udstede SOSI Idkort der gør det muligt for anvendere at tilgå DGWS services på National Service Platform f.eks. MinSpærring, DRS eller andre Forretningsservices.

Overordnet set kan der udstedes følgende SOSI IdkortOverordnet set kan der udstedes følgende SOSI Idkort:

• 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 lægefaglig 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:

Pilene på tegningen viser følgende flow:

1. Anvendersystemet bygger et SOSI Idkort indeholdende informationer om brugeren/systemet og signerer det med det 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.

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. Der er en whitelist for trustede CVR-organisationer, som selv administrere nationale roller lokalt. For disse trustes den nationale rolle der er claimet - dvs. ingen opslag i 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 SOSI STS'ens certifikat ernes certifikater er kendt kendte af alle komponenter i føderationen.

...

Anvendelse: Medarbejderomveksling

STS indeholder to tre services til brug for medarbejderomveksling. Det drejer sig om en service, der kan veksle et :

• Omveksling fra Bruger SOSI Idkort til

...

• OIO SAML billet

...

• Omveksling fra OIO SAML billet til Bruger SOSI Idkort

...

• Omveksling fra OIO Saml bootstrap token til Bruger SOSI Idkort (en videreudvikling af SOSI sikkerhedsinfrastrukturen så den understøtter 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 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 at 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 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. I det viste eksempel giver den 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.

Den anden type De to sidste typer af medarbejderomveksling veksler fra en gyldig OIO SAML billet til et Bruger SOSI Idkort. Flowet er illustreret i diagrammet nedenfor.

Pilene på tegningen viser følgende flow:

1. Anvendersystemet er i besiddelse af en OIO SAML billet eller en OIOSAML-baseret bootstraptoken for en given medarbejder (i praksis udstedt af NemLoginaf SEB eller andre af SOSI STS trustede lokale IdP'er/udstedere). Denne OIO SAML billet 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 det den indgående OIO SAML 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 NemLoginudstedt af 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 (den 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 (udfra . Det gøres ud fra RID oplysninger i OIO SAML billetten) vha CPR-RID servicebilletten (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 Hvis en medarbejder identificeret i den indkommende OIO SAML billet har netop én national rolleautorisation i autorisationsregisteret, så vil denne automatisk indsættes i indsættes i det udstedte SOSI Idkort uden at anvendersystemet claimer rollen.
   6. Hvis anvendersystemet hverken har claimet et autorisationsnummer for medarbejderen, så valideres dette op i mod autorisationsregisteretrolle 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 er to typer af borgeromvekslinger:

• Omveksling fra JWT til OIO SAML sikkerhedsbillet
• Omveksling fra JWT/bootstrap token til OIO IDWS sikkerhedsbillet

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.  Den udstedte billet krypteres til det ønskede audience og er tiltænkt anvendt til 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.

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 :

Adgang til STS

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).
  • 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.
• Anvenderen skal oprettes som anvender til STS. 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.
  • Angivelse af hvilke omvekslingsservices, der ønsker benyttet.
  • Ekstra informationer (i forbindelse med de enkelte STS services) inkluderes. Brug tabellen nedenfor.

...

Det skal oplyses, hvilket NSP audience, der ønskes veklses til (se TODO)

Det skal oplyses, hvilken udsteder af JWT tokens, der anvendes. Hvis det er en ny udsteder, så kræver oprettelsen mere end en supporthenvendelse.

Det skal angives, hvilke scopes, der inkluderes i JWT token, og hvorledes disse skal mappes til NSP audience.

----kladde nedenfor...skal lige finde ud af, hvor det skal være.

Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services inden for en føderation [SOSI] på sundhedsdatanettet.

Snitfladen SecurityTokenService er en legacy udgave af NewSecurityTokenService. I NewSecurityTokenService overskrives NameID/AlternativeIdentifier, hvilket vil sige at anvender ikke kan bestemme indholdet heraf.

Snitfladerne beskrives detaljeret her:
STS - Guide til anvendere - Signering af id-kort 

...

Som et

Ønsker jeg at

Så jeg kan

...

IT system

få udstedt et SOSI Idkort på baggrund af et certifikat (MOCES/VOCES/FOCES)

fortage et servicekald mod en DGWS beskyttet forretningsservice på NSP

Anvendelse: DGWS

...

Som et

Ønsker jeg at

Så jeg kan

...

IT system

få udstedt et SOSI Idkort på baggrund af et certifikat (MOCES/VOCES/FOCES)

fortage et servicekald mod en DGWS beskyttet forretningsservice på NSP

Anvendelse: DGWS

...

Som et

Ønsker jeg at

Så jeg kan

...

IT system

få udstedt et SOSI Idkort på baggrund af et certifikat (MOCES/VOCES/FOCES)

fortage et servicekald mod en DGWS beskyttet forretningsservice på NSP

Introduktion

Formål

Denne guide har som formål at give et overblik over STS.

Nærværende dokument henvender sig til nuværende og kommende brugere af STS (Security Token Service) og formålet med dokumentet er, at give hjælp til disse i arbejdet med integration mod STS. Dette sker ved en overordnet gennemgang af de udstillede services og beskrivelse af specifikke elementer, der er væsentlige for at opnå en basal forståelse på anvenderniveau. Gennemgangen kan være understøttet af ekstern dokumentation. STS og relaterede services udstilles som webservices og i produktion altid på sundhedsdatanettet, hvilket kræver separat tilslutning.

Begreber

...

Beskrivelse

Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services inden for en føderation [SOSI] på sundhedsdatanettet.

I dette afsnit beskrives de væsentlige faser, som eksisterer ifbm. behandlingen af en forespørgsel til STS. Undervejs vil de væsentlige begreber og elementer, der indgår i en forespørgsel være forklaret. Der henvises endvidere til yderligere dokumentation, hvor det er relevant, så helheden og meningen fremgår.

Grafisk fremstilling og sammenhængen

Arkitekturoverblik

...

Oversigt over snitflader STS

...

Udstedelse af STS-signeret id-kort.

...

Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt

...

Ombytter STS-signeret id-kort til OIOSaml-token rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af /sts/services/NewSecurityTokenService

...

Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart
(nemlogin)

...

Ombytter OIOSaml bootstrap token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart(nem-login)

...

Ombytter JSON Web token til signeret identity-token rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (pt. en OID connector)

Pilene på tegningen viser følgende flow:

1. Anvendersystemet er i besiddelse af en JWT eller bootstrap token for en borger (i praksis udstedt 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.

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

Adgang til STS

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

De konkrete krav variere fra service til service. Nedenstående tabel viser de krav, der hører til de konkrete snitflader.

Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen) til flere af de ovenstående services.

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. Se feks. https://www.nets.eu/dk-da/kundeservice/nemid-tjenesteudbyder/implementering/Pages/adgang-til-testsystem.aspx

For de services, hvor anvenderen skal konfigureres i SOSI STS (feks whitelisting), skal der rettes henvendelse til servicedesk på nspop.dk.

Henvendelsen skal indeholde oplysninger om:

• • Den service, der ønskes anvendt
  • De informationer, der skal konfigureres. Brug tabellen ovenfor

Læsevejledning og forudsætninger

En typisk anvender af STS, som kan drage nytte af dette dokument er karakteriseret ved eksempelvis at være leverandør af et lægepraksissystem eller leverandør af et fagsystem implementeret på et hospital, f.eks. et laboratoriesystem eller et medicineringssystem.

Id-kort spiller en central rolle for single-signon scenariet, der understøttes af STS, og det er en absolut nødvendighed med en god forståelse af begreberne for at arbejde med STS. Id-kortet anvendes ifm. autentifikation og autorisation af en bruger, der opererer på sundhedsdatanettet via en serviceaftager.

Specifikationen af DGWS [DGWS] har en god og uddybende beskrivelse af, hvordan et id-kort er konstrueret og kan anvendes i praksis.

Definitioner og referencer

...

Dokument historik

...

Sammenskrivning af oprindelige anvendergudier og yderligere informationer

STS begreber

Identitetsservice

Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er der en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider). På NSP hedder servicen Security Token Service (STS).

Introduktionen af STS betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.

Føderation, ombytning af id-kort og servicekald

Følgende er et eksempel på hvad der sker i de forskellige skridt når en anvender ombytter sit id-kort til et signeret af STS:

1. Anvendersystemet bygger et id-kort indeholdende informationer om brugeren/systemet og signerer det med brugerens/systemets certifikat.

2. Id-kortet sendes til STS, der tjekker at signaturen er korrekt og baseret på et OCES-certifikat udstedt under det samme rodcertifikat som STS's eget.

3. Korrektheden af attributter som personnummer og autorisation verificeres af STS. Ydermere tjekkes det om certifikatet er spærret for anvendelse.

4. STS opbygger et nyt id-kort med de samme informationer og signerer det med STS'ens eget certifikat. Den offentlige nøgle i dette certifikat er kendt af alle komponenter i føderationen.
5. STS sender det nye id-kort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
6. Anvendersystemet indsætter nu det nye id-kort i headeren på alle fremtidige forespørgelser mod NSP-komponenter.
7. NSP-komponenten verificerer at id-kortet er signeret af føderationens certifikat, og stoler herefter på udvalgte dele af id-kortet.

...

Bemærk at et id-kort kan anvendes til flere forespørgelser, så længe det endnu ikke er udløbet.

Offentlige Certifikater til Elektronisk Service

Til generel identifikation, dels som anvender overfor STS og dels for id-kortet overfor services på NSP, kræves digitale certifikater. På NSP skal disse overholde den fælles offentlige standard for certifikater. Standarden hedder OCES, Offentlige Certifikater til Elektronisk Service.

OCES-certifikater

OCES certifikater indeles i fire hovedgrupper, hvoraf de tre anvendes på NSP:

• Medarbejdercertifikat (MOCES)
  Udstedes til en medarbejder af en virksomhed og anvendes til autentifikation af den person, der udfører en handling ifm. sin ansættelse i virksomheden.
• Virksomhedscertifikat (VOCES)
  Udstedes til virksomheder og anvendes til autentifikation af selve virksomheden.
• Funktionscertifikat (FOCES)
  Udstedes til virksomheder og bruges til autentifikation af en applikation, en enhed, en proces eller en service.

Den sidste gruppe af certifikater betegnes som Personcertifikater, og udstedes til identifikation af privatpersoner.

Digitaliseringsstyrelsen og Nets DanID

Alle OCES-certifikater udstedes af Nets DanID der varetager denne opgave for Digitaliseringsstyrelsen. Nets DanID har et rodcertifikat og herunder en række krydscertifikater som bruges til at udstede OCES-certifikaterne. Specielt kan det nævnes at det certifikat, en STS service er konfigureret med, blot er endnu et udstedt certifikat, ganske som alle andre udstedte certifikater. Dog definerer dette certifikat den omtalte føderation. I praksis er det anvender-bibliotekerne Seal.Java og Seal.Net, der kender til dette certifikat og dermed kan verificere id-kort med en signatur, der stammer fra certifikatet.

Fælles offentlig brugerstyring (NemLog-In)

Fællesoffentlig brugerstyring skal gøre det digitale Danmark mere sikkert, mindske investeringerne i infrastruktur for offentlige myndigheder og skabe bedre service for borgerne. Dette sker ved at lade en række webapplikationer og webservices indgå i en fælles føderation (sikkerhedskontekst).

Brugeren autentificeres ved anvendelse af NemLog-in og får hermed adgang til alle applikationer og services inden for NemLog-in føderationen (Single sign-on). Autentifikation med NemLog-In kan enten være baseret på NemId (papkort) eller anvendelse af digital signatur (OCES-certifikater).

NemLog-In er leveret af NNIT og har Digitaliseringsstyrelsen som operatør og CSC som driftsleverandør.

En oversigt over relevante materialer findes på http://www.digst.dk/Loesninger-og-infrastruktur/NemLogin/Det-nye-nemlogin. En kort intro til NemLog-In kan ses under http://www.digst.dk/Loesninger-og-infrastruktur/NemLogin/Det-nye-nemlogin.

Adgang til NemLog-in føderationen

Når en uidentificeret bruger tilgår en webapplikation, der indgår i NemLog-In føderationen, foretages autentifikation ikke af webapplikationen selv, men derimod med anvendelse af NemLog-In som Identity Provider (IdP).

Brugeren videredirigeres til IdP'en i form at et autentifikationsrequest. IdP'en efterspørger om nødvendigt credentials fra brugeren (i form af digitalt certifikat eller papkort) og dirigerer herefter brugeren tilbage til webapplikationen med et krypteret token.

Det krypterede NemLog-in token er altid målrettet en given webapplikation. Det er signeret af NemLog-in og krypteret med webapplikationens offentlige nøgle og kan derfor kun anvendes af denne applikation. Dekryptering åbner op for at aflæse de indeholdte informationer omkring brugerens identitet.

Applikationen har tillid til NemLog-in (trust) og kan derfor stole på de oplysninger dette token indeholder.

...

Undervejs etableres en browser-session med NemLog-In IdP'en, som gør det muligt at undgå gentagen afgivelse af credentials ved tilgang til en anden webapplikation indenfor føderationen (Single sign-on). Samme session mellem bruger og IdP kan således give adgang til flere webapplikationer - ved at føde et NemLog-In token for hver applikation.

NemLog-in token

Et NemLog-In token er et eksempel på en OIO-SAML assertion. OIO-SAML er en dansk profilering af den internationale SAML 2.0 standard. Dvs. man har taget standarden og skræddersyet den til danske forhold - herunder f.eks. hvordan cpr- og cvr-numre kan anvendes til at identificere personer og virksomheder.

Endvidere findes en OCES subprofil, som beskriver andre relevante ting f.eks. at en OIO-SAML assertion er udstedt på baggrund af et OCES-certifikat. Indholdet er beskrevet i OIO-SAML-Profil.

Den udstedte OIO-SAML assertion er møntet på et enkelt audience (system) - ved kryptering sikres det, at det kun kan anvendes af det tilsigtede system. Dette token kan derfor betragtes som en "personlig billet" der giver en bruger adgang til et givet system.

En OIO-SAML assertion (og dermed et NemLog-In token) udstedt på baggrund af OCES-certifikat indeholder følgende elementer:

• Issuer. Den IdP (typisk NemLog-In) der har udstedt token.
• Signature. Udsteders digitale signatur af det samlede token. Signaturen kan verificeres med udsteders offentlige nøgle.
• Subject. Anvenders identitet. Ved udstedelse på baggrund af OCES-certifikat skal dette være certifikatets Distinguished Name.
• Conditions. Beskriver gyldighed af token, herunder tidsperiode samt hvilket audience (aftagersystem) dette token er rettet mod. Token er krypteret med offentlig nøgle for aftagersystemet.
• AuthnStatement. Beskriver hvordan anvenders identitet er bekræftet. I nærværende sammenhæng altid via X.509 (OCES) certifikat.
• AttributeStatement. Indeholder et antal attributter (udsagn) omkring brugeren f.eks. navn, email og organisatoriske tilhørsforhold. Beskrevet nærmere nedenfor.

Attributter i et NemLog-In token

Et token indeholder en række attributter, hvoraf nogle er obligatorisk for alle OIO-SAML assertions, mens andre kun er relevante, hvis de er udstedt på baggrund af OCES-certifikater (som ifm. billetomveksling).

Attributter som er obligariske for alle OIO-SAML assertions:

• oid:2.5.4.4 (surName). Brugerens efternavn.
• oid:2.5.4.3 (commonname). Brugerens fulde navn.
• oid:0.9.2342.19200300.100.1.1 (uid). Beskriver brugerens id i context af hans organisation. For assertions udstedt på baggrund af OCES-certifikater skal dette være certifikatets subjectSerialNumber (CVR-RID).
• oid:0.9.2342.19200300.100.1.3 (email). Brugerens email-adresse.
• AssuranceLevel. Angiver pålidelighed af data i henhold til Vejledning vedrørende niveauer af autenticitetssikring, typisk 3 eller 4.
• SpecVer. Beskriver OIO-SAML version, pt. DK-SAML-2.0

For assertions udstedt på baggrund af OCES-certifikater er yderligere en række attributter obligatoriske:

• oid:2.5.4.5 (serialNumber). Serienummer på brugerens OCES-certifikat.
• oid:2.5.29.29 (certifikat udsteder). Udsteder af certifikatet. Enten rodcertifikatet eller et underliggende krydscertifikat. Sammen med serienummer identificerer dette certifikatet unikt.
• oid:2.5.4.10 (organizationName). Brugerens organisation. Obligatorisk ved VOCES/MOCES certifikat.
• IsYouthCer. Angivelse af om det er et særligt ungdomscertifikat udstedt til personer i alderen 15-18 år, som kan identificere brugeren men ikke anvendes til juridisk bindende aftaler.
• CvrNumberIdentifier. CVR-nummer for brugerens organisation. Obligatorisk ved MOCES/VOCES certifikat.
• RidNumberIdentifier. Obligatorisk ved MOCES-certifikat og hentet herfra.

OIO-SAML beskriver yderligere nogle relevante attributter, som ikke er obligatoriske:

• oid:1.3.6.1.4.1.1466.115.121.1.8 (userCertificate). Det certifikat der er baggrund for udstedelse af token. Optionelt, men er indeholdt i NemLog-In tokens og kræves af STS billetomveksling.
• CprNumberIdentifier. Brugerens CPR-nummer. Optionelt og kun tilladt under visse omstændigheder (bl.a. at aftager skal være en offentlig instans).

SOSI Id-kort

I modsætning til de generelle OIO-SAML assertions udstedt af NemLog-In, er et SOSI id-kort skræddersyet til anvendelse i fagsystemer indenfor sundhedsvæsenet. Der er nogle væsentlige forskelle mellem SOSI id-kort og OIO-SAML tokens:

• Det samme SOSI id-kort kan være adgangsgivende til flere services fra flere kaldende it-systemer, hvorimod en OIO-SAML assertion kun kan anvendes til et enkelt modtagende system.
• Et SOSI id-kort indeholder typisk enkelte sundhedsspecifikke attributter som f.eks. et autorisationsnummer, der kan anvendes af modtagende it-systemer.
• Et SOSI id-kort anvendes til at tilgå webservices mens en OIO-SAML assertion anvendes af webapplikationer (men kan indeholde et bootstrap token der kan veksles til adgangsbilletter til webservices).
• Et SOSI id-kort er et eksempel på en SAML assertion men opfylder ikke betingelserne i henhold til OIO-SAML profilen, og er derfor ikke en OIO-SAML assertion.

STS billetomveksling kan anvendes til at veksle mellem de to slags tokens. Det muliggør at autentifikation (udstedelse af id-kort) overfor STS'en kan omveksles til adgang til systemer indenfor NemLog-In føderationen som f.eks. sundhed.dk.

Opbygning

Id-kortet er det bærende element ifm. signering i STS'en. Som beskrevet i platformsintroduktionen er id-kortet et XML-dokument der indeholder informationer om den person, virksomhed eller applikation, som foretager en forespørgsel mod en NSP-service. Når man ombytter et id-kort i STS'en, placeres id-kortet under SOAP Body elementet. Når man medsender et id-kort ifm. kald af NSP-services placeres det under SOAP Header elementet.

...

Attributter

Et id-kort består af en mængde attributter som anvendersystemet udfylder. En del af disse attributter bliver verificeret af STS, og nogle bliver valideret af komponenterne. Verifikationen i STS gennemgås i næste hovedafsnit.

• Navn: En identifikation af den person/organisation som id-kortet skal repræsentere. Hvis der ikke angives et navn anvender Seal enten brugerens CPR-nummer eller organisationens id.
• Id: Et internt, unikt id, der genereres af Seal.
• Oprettet: Det tidspunkt id-kortet er oprettet og derved gyldigt fra.
• Udløber: Det tidspunkt id-kortet udløber.
• Udsteder: Navnet på den instans, der har udstedt id-kortet. Hver STS-service har sin egen streng. Det er det muligt for anvendere at angive denne, når der genereres et id-kort.
• Autentifikationsniveau: Ved brug af STS er der kun to valide muligheder for autentifikationsniveau; 3 hvis der er tale om et systemid-kort signeret med et VOCES-certifikat eller FOCES-certikat, eller 4, hvis der er tale om et brugerid-kort signeret med et MOCES-certifikat.
• Organisation: Navnet, typen og et id for den organisatoriske enhed som id-kortet repræsenterer. Typen kan være CVR-nummer, en SKS-kode, et yder-nummer eller et p-nummer (Produktionsenhedsnummer).
• IT System: Navnet på det system der initierede forespørgslen. Dette er en fritekst, der kan indsættes af anvendersystemet og vil blive bevaret i det STS signerede id-kort. I nogle tilfælde bruges denne værdi af NSP-komponenter. F.eks. bruges værdien af NAS til at identificere et Pullpoint.

Hvis der er tale om et brugerid-kort er følgende attributter også tilstede

• Bruger: CPR-nummeret, fulde navn og email-adresse på den person som id-kortet repræsenterer.
• Rolle: Den firecifrede uddannelseskode som brugerens autorisation har. Koderne i autorisationsregistret er et subset af uddannelseskoderne fra Danmarks Statistik. Som eksempel kan nævnes at uddannelseskoden 7170 bruges for læger og 5166 bruges for sygeplejersker.
• Autorisationsid: Det autorisationsID som brugerens autorisation har. En anvender har en eller flere autorisationer, hvert med et unikt ID og en uddannelseskode.
• Ansættelse: Den ansættelse i organisationen som brugeren har. Denne værdi er en fritekst og bevares i det STS-signerede id-kort.

Certifikat og signatur

Når et id-kort signeres, enten af anvenderen eller af STS, bliver certifikatets offentlige nøgle lagt ind på id-kortet og kortet signeres med certifikatets private nøgle. Seal-bibliotekerne udfører disse opgaver for een. Hvis man ønsker at vide hvordan det praktisk foregår, så er hele processen beskrevet i "Den Gode Webservice" [DGWS].

Billetomveksling

NemLog-In token til id-kort

STS kan anvendes til omveksling af særlige OIO-SAML assertions til et ækvivalent id-kort der kan anvendes til at få adgang til NSP-platformen. Visse oplysninger fremgår af et SOSI id-kort men ikke af et NemLog-In token. Disse skal derfor angives eksplicit i forespørgslen som supplerende information, i det omfang de ikke automatisk kan fastlægges.

Omveksling kræver:

• Det skal være en OIO-SAML assertion udstedt og signeret af en IdP som STS'en stoler på. Dette betyder i praksis NemLog-In.
• Det skal være et OIO-SAML token udstedt på baggrund af et MOCES-certifikat.
• Det skal have AssuranceLevel 3 eller 4 (opfyldt for tokens udstedt på baggrund af OCES-certifikat).
• Medarbejderens CPR-nummer skal enten være angivet i forespørgslen eller kunne bestemmes ud fra certifikatet.
• Autorisationsnummer og uddannelseskode skal enten være angivet i forespørgslen eller kunne bestemmes entydigt (ud fra CPR-nummer og autorisationsregister).
• It-system-navn skal være angivet i forespørgslen da dette ikke indgår i et NemLog-In token.

Herudover kan man vælge at medsende brugerens fornavn/efternavn i forespørgslen, idet fornavnet ikke kan bestemmes ud fra en OIO-SAML assertion.

Såfremt omvekslingen går godt, vil slutresultatet være et STS-signeret id-kort med oplysninger sammensat fra NemLog-In token, supplerende info og opslag, som herefter kan benyttes som adgangsbillet til NSP-platformens services.

Validering af signaturer

STS'en verificerer at forespørgslen er signeret med et gyldigt certifikat (ikke udløbet, ikke spærret), som er udstedt af rodcertifikatet (eller af et af krydscertifikaterne).

STS'en verificerer at den indeholdte OIO-SAML assertion er signeret med et gyldigt certifikat (ikke udløbet, ikke spærret), som er udstedt af rodcertifikatet (eller af et af krydscertifikaterne). Herudover skal det være et certifikat som STS'en stoler på. STS'en er derfor konfigureret med trust af en eller flere kilder. I produktion stoles i skrivende stund alene på NemLog-In.

Håndtering af CPR-nummer

Brugerens CPR-nummer er valgfrit i en OIO-SAML assertion. Såfremt dette er medsendt, valideres korrektheden ved opslag ud fra det medsendte CvrRid. Alternativt vil det blive fremsøgt. Herved sikres at det returnerede id-kort altid indeholder et CPR-nummer, hvis ægthed er bekræftet.

Håndtering af autorisationsnummer og uddannelseskode

Hvis brugeren har en autorisation i henhold til autorisationsregisteret, skal denne være beskrevet i et STS-signeret id-kort med autorisationsnummer og uddannelseskode. Disse er ikke indeholdt i en OIO-SAML assertion, men kan være medsendt som supplerende information i billetomvekslingsforespørgslen.

Disse håndteres på følgende måde:

• Hvis både autorisationsnummer og uddannelseskode er medsendt, verificeres disse via autorisationsregisteret og indsættes i det returnerede id-kort.
• Hvis enten autorisationsnummer eller uddannelseskode er medsendt, verificeres at dette matcher præcis én autorisation i autorisationsregisteret, og denne indsættes i det returnerede id-kort.
• Hvis hverken autorisationsnummer eller uddannelseskode er medsendt, verificeres at brugeren har præcis én autorisation i autorisationsregisteret, og denne indsættes i det returnerede id-kort.

Det er den samme algoritme, der anvendes ved signering.

Id-kort til OIO-SAML assertion.

STS tilbyder ligeledes omveksling af id-kort til OIO-SAML assertions rettet mod udvalgte it-systemer. I forespørgslen angives:

• Et gyldigt STS-signeret id-kort niveau 3 eller 4 (dvs. baseret på et MOCES-, VOCES- eller FOCES-certifikat).
• Et audience, dvs. navnet på den webaplikation, som det udstedte token skal gælde for.

Det angivne audience skal være kendt af STS'en. STS'en vil kvittere med en gyldig OIO-SAML assertion signeret af STS og rettet mod den angivne webapplikation. Denne assertion er baseret på oplysningerne i id-kortet, samt suppleret med information som STS er konfigureret med for den givne applikation.

Endvidere krypteres med webapplikationens offentlige nøgle, så token kun kan verificeres og anvendes til denne ene applikation. Det oprindelige id-kort medsendes evt. (afhænger af konfiguration) som en del af den returnerede assertion, så den webapplikation der kaldes har dermed direkte adgang til services på NSP-platformen uden at skulle foretage en omveksling.

Billetomvekslingen kan således anvendes af alle med adgang til NSP. Men kan kun veksle til en assertion som giver adgang til et system kendt og konfigureret i STS.

Konfiguration af audience i STS.

For at tilgå et tredjepartssystem (f.eks. sundhed.dk) via billetomveksling, skal dette være kendt af og konfigureret i STS. Konfigurationen omfatter:

• navn på audience - benyttes som nøgle og er formatteret som en URI.
• Certifikat for dette audience - benyttes til kryptering af det returnerede token, så kun dette audience kan aflæse informationen.
• recipient - loginUrl hos den webapplikation som det returnerede token skal anvendes på.
• includeBootstrapToken - angivelse af hvorvidt det fremsendte id-kort skal rummes i det returnerede token. Bemærk at en OIO-SAML assertion udstedt af STS ikke kan veksles tilbage til et id-kort. Med inkludering af bootstrap token bliver dette unødvendigt.
• diverse tekniske attributter der benyttes til at beregne hvilken periode den returnerede OIO-SAML assertion vil være gyldig i.

Bemærk, at da det returnerede OIO-SAML token indeholder brugerens CPR-nummer sætter det visse juridiske begrænsninger (persondataloven) for hvilke webapplikationer det er muligt at konfigurere.

Anvendelse af billetomveksling

Billetomveksling kan anvendes af et fagsystem (f.eks. et EPJ-system), som allerede har et gyldigt id-kort for den aktuelle bruger, til at integrere med en fremmed webapplikation.

Integrationen foregår på følgende måde:

• Fagsystemet ABC kalder billetomveksling med det STS-signerede id-kort samt angivelse af applikationen XYZ og signerer hele forespørgslen med eget certifikat.
• STS validerer forespørgslens signatur, konstaterer at XYZ er et kendt audience, og returnerer en gyldig OIO-SAML assertion, signeret af STS og krypteret med XYZ's offentlige nøgle.
• ABC åbner en browser på brugerens lokale PC som kalder en adresse (URL) hos fagsystemet.
• Den kaldte adresse (URL) redirigerer herefter til XYZ med OIO-SAML assertion indlejret (typisk som en formular i et HTTP POST request).
• XYZ dekrypterer assertion med egen private nøgle.
• XYZ verificerer at OIO-SAML assertion er signeret af en troværdig IdP og betragter herved brugeren som autentificeret.

...

Hele processen kræver således gensidigt kendskab og aftale mellem STS og den eksterne webapplikation XYX, idet

1. STS skal kende den eksterne applikation og være konfigureret med bl.a. dennes offentlige nøgle
2. XYZ skal kende til STS'en som en troværdig IdP og dermed stole på assertions signeret af STS.

Verifikation

Når STS'en modtager en signeringsforespørgsel verificeres id-kortet og anvenderens certificat i flere skridt. Disse skridt er kort beskrevet i de følgende afsnit, og er yderligere uddybet i STS dokumentationen. Verifikationen betyder at komponenter kan stole på korrektheden af de nævnte attributer, hvis id-kortet er signeret af STS'en.

Gyldighed

Et id-kort er kun gyldigt i en bestemt periode. STS'en tjekker derfor at denne periode er oplyst på id-kortet og at det indeholder kaldstidspunktet. Dette gøres for at sikre at man ikke kan udstede et id-kort, der først bliver gyldigt en gang ude i fremtiden.

Et id-kort kan maksimalt være gyldigt i 24 timer, derfor tjekker STS at den ønskede gyldighedsperioden ikke er længere end 24 timer.

Certifikat

Det certifikat, som anvender har brugt til at signere id-kortet i forespørgslen, skal være signeret af Nets DanID's rodcertifikatet (eller af et af krydscertifikaterne). Da der findes flere gyldige sæt af disse (test og produktion), er det vigtigt at anvender har styr på hvilket sæt den kaldende STS er en del af.

Spærrelister

Selv om et certifikat er korrekt udstedt til føderationen, kan det godt blive nægtet adgang. Dette sker ved hjælp af en såkaldt blackliste, der indeholder certifikater, der ikke længere må anvendes. Denne liste vedligeholdes som en del af certifikatinfrastrukturen og anvendes af STS til at afvise certifikater, der f.eks. er blevet kompromiteret eller på anden måde har mistet deres autoritet.

CVR-nummer

STS verificerer at det angivne CVR-nummer matcher det CVR-nummer, der er angivet i certifikatet.

Personnummer

Hvis forespørgslen indeholder et brugerid-kort tjekkes at det angivne personnummer matcher det personnummer, der blev brugt da medarbejdercertifikatet blev udstedt. Verifikationen anvender en ekstern webservice til at finde det personnummer der er knyttet til CVR/RID-nummeret i certifikatet. Hvis der ikke var tilknyttet er CPR-nummer til certifikatet ved udstedelse, så kan dette certifikat ikke bruges til at få et signeret id-kort.

Autorisation

Hvis forespørgslen indeholder et brugerid-kort, så laves der et opslag i autorisationsregisteret for at finde den autorisation, som brugeren anvender. Hvis der er angivet en rolle og/eller et autorisationsID i forespørgelsen, anvendes disse til at udvælge autorisationen. I "STS Anvender dokumentet" er udvælgelsesalgoritmen beskrevet i detaljer. Den følgende liste beskriver de gængse situationer med angivelse af autorisation. Disse situationer er også indeholdt i medfølgende eksempler.

• En bruger med en autorisation: hvis en bruger kun har en autorisation kan denne angives eller helt undlades og dermed lade STS vælge den ene.
• En bruger med flere autorisationer: anvendere skal her angive nok information for STS til at finde en entydig autorisation.
• En bruger uden autorisationer: her skal anvendere undlade at angive en gyldig autorisation.

Den konkrete udformning af forespørgelsen til STS kan ses i eksemplerne.

Signering af id-kort

Adgang

...

/sts/services/NewSecurityTokenService

/sts/services/SecurityTokenService

...

Udstedelse af STS-signeret id-kort.

Snitfladebeskrivelse og brug

Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services inden for en føderation [SOSI] på sundhedsdatanettet.

Snitfladen SecurityTokenService er en legacy udgave af NewSecurityTokenService. I NewSecurityTokenService overskrives NameID/AlternativeIdentifier, hvilket vil sige at anvender ikke kan bestemme indholdet heraf.

Snitfladerne beskrives detaljeret her:
STS - Guide til anvendere - Signering af id-kort 

Medarbejder-Billetomveksling

Adgang

...

/sts/services/OIOSaml2Sosi

/sts/services/Sosi2OIOSaml

/sts/services/JWT2OIOSaml

...

Kan veksle mellem OIOSaml (nem-login) token og signeret id-kort, hvor token skal være signeret af troværdig tredjepart (nemlogin).

Kan veksle fra JWT til OIOSAML, hvor JWT er udstedet og signeret af en OpenID connect server.

Ombytter STS-signeret id-kort eller JSON Web Token til OIOSaml-token rettet mod et specifikt audience, f.eks. sundhed.dk eller forløbsplaner.dk.

Snitfladebeskrivelse og brug

Formålet med omvekslingen er:

At tillade web-løsninger, hvis anvendere er logget på via NemLog-in anvendere af NemLogin at kalde foretage DGWS-kald, som kræver SOSI id-kort, ved at veksle en eksisterende OIOSAML-assertion udstedt af NemLog-intil et id-kort, som efterfølgende kan anvendes til opslag af webservices hos f.eks. NSP eller FMK.

At tillade anvendere af id-kort at foretage kald i NemLogin federationen, som kræver OIOSAML assertions, ved at veksle et eksisterende id-kort til et OIOSAML-assertion.

At tilbyde borgeren login-funktionalitet via en OpenID connect server, hvor et såkaldt JSON Web Token (JWT) udstedt til borgeren og signeret af OpenID serveren herefter kan veksles til

Snitflade OIOSaml2Sosi beskrives detaljeret her:
STS - Guide til anvendere - Medarbejder-Billetomveksling til signeret id-kort

Snitflade Sosi2OIOSaml og  JWT2OIOSaml beskrives detaljeret her:

STS - Guide til anvendere - Medarbejder-Billetomveksling til OIOSAML

Borger-Billetomveksling

Adgang

...

/sts/services/Bst2Idws

/sts/services/JWT2Idws

...

Ombytter OIOSaml bootstrap token eller JWT til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (nem-login)

Snitfladebeskrivelse og brug

Formålet med omvekslingen er:

At tillade web-løsninger, hvis anvendere er logget på via NemLog-in, at kalde foretage IDWS-kald, som kræver IDWS identitytoken, ved at veksle en eksisterende OIOSAML- eller JWT-asserteion udstedt af NemLog-in til et identitytoken, som efterfølgende kan anvendes til opslag af webservices hos f.eks. FSK eller FMK.

At tillade anvendere af identitytoken at foretage kald i NemLogin federationen, som kræver OIOSAML assertions, ved at veksle et eksisterende identitytoken til et OIOSAML-assertion.

At tilbyde borgeren login-funktionalitet via en OpenID connect server, hvor et såkaldt JSON Web Token (JWT) udstedt til borgeren og signeret af OpenID serveren herefter kan veksles til

Snitflade OIOSaml2Sosi beskrives detaljeret her:
STS - Guide til anvendere - Borger-Billetomveksling til IDWS

Fejlbeskeder

Behandling af forespørgsel

Ved behandling af en forespørgsel om udstedelse af ID-kort hos en STS gennemgås en række skridt. Forløbet er skitseretforsimplet nedenfor, med de skridt der har primær relevans i forhold til diagnosticering af udstedelse. Hvert skridt kan føre til en afvisning af forespørgslen, mens succesfuld verifikation leder til signering og dermed udstedelse af et ID-kort.

Verificeret forespørgsel

Ved succesfuld udstedelse af et STS signeret ID-kort returneres et SOAP svar fra STS indeholdende relevante ID-kort attributter(SAML assertions), dvs. både verificerede (f.eks CVR) og berigede (f.eks. CPR), samt øvrig information jævnfør DGWS.

<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope ...="...">
  <soapenv:Header>
    <wsse:Security id="AAABL0ncNMXd26QUzOR4JlNPU0k=">
      <wsu:Timestamp>
        <wsu:Created>2011-04-12T15:17:41</wsu:Created>
      </wsu:Timestamp>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <wst:RequestSecurityTokenResponse Context="www.sosi.dk">
      <wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion:</wst:TokenType>
      <wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
      <wst:Status>
        <wst:Code>http://schemas.xmlsoap.org/ws/2005/02/trust/status/valid</wst:Code>
      </wst:Status>
      <wst:Issuer>
        <wsa:Address>TESTSTS</wsa:Address>
      </wst:Issuer>
    </wst:RequestSecurityTokenResponse>
  </soapenv:Body>
</soapenv:Envelope>

Ovenstående eksempel viser en del af et svar indeholdende et STS signeret ID-kort. I eksemplet er namespace erklæringer samtalle ID-kort attributter fjernet af hensyn til overskuelighed. Vigtige elementer ved diagnosticering er:

• wsu:Timestamp: Tidspunkt for udstedelse
• wst:RequestSecurityTokenResponse: Findes altid for succesfuldt udstedte ID-kort
• wst:RequestedSecurityToken: Indeholder ID-kortets attributter
• wst:Status: Indeholder status for ID-kortet (WS-Trust)
• wst:Issuer: Viser hvilken STS (føderation) ID-kortet er udstedt af

Afvist forespørgsel

På tilsvarende vis leverer en STS ved afvist forespørgsel et SOAP svar (Fault) indeholdende yderligere information om fejlen.  Nedenstående eksempel viser (igen uden namespace erklæringer) elementerne i svaret der bruges i forbindelse med diagnosticer-ing:

• wsu:Timestamp: Tidspunkt for behandling
• faultcode: Kategorisering af årsag til afvisning
• faultactor: Information om afvisningens oprindelse
• faultstring: Kort beskrivelse af årsagen til afvisningen

Det er kombinationen affaultcode, faultactor og faultstring som identificerer fejlen, hvor faultstring typisk indeholder den nødvendige information for nærmere fejlsøgning.

Faultcode værdier faultcode skal ikke betragtes som entydige fejlkoder, men skal ses i sammenhæng og bør betragtes som en gruppering af de fejltyper der kan opstå ved behandling af kald til tjenester på en STS:

• wst:InvalidRequest
• wst:FailedAuthentication
• wst:RequestFailed
• wst:AuthenticationBadElements
• wst:BadRequest
• wst:InvalidTimeRange

FAULTACTOR VÆRDIER

• dk:sosi:sts: Fejl ved behandling af ID-kort udstedelse
• dk:sosi:sts:its: Fejl ved veksling af SAML token identity token
• dk:sosi:sts:nbo: Fejl ved billetomveksling
• dk:sosi:sts:seal: Fejl ved håndtering af ID-kort, f.eks. verifikation af signatur og serialisering/deserialisering
• dk:sosi:sts:cvrridcpr: Fejl ved opslag i RID-CPR tjeneste eller brug af resultatet fra opslaget
• dk:sosi:sts:autorisation: Fejl ved opslag i autorisationsregister eller brug af resultatet fra opslaget

<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope ...="...">
  <soapenv:Header>
    <wsse:Security id="">
      <wsu:Timestamp>
        <wsu:Created>2011-04-12T15:17:39</wsu:Created>
      </wsu:Timestamp>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <soapenv:Fault>
      <faultcode>wst:InvalidRequest</faultcode>
      <faultstring>The request was invalid or malformed</faultstring>
      <faultactor>dk:sosi:sts</faultactor>
    </soapenv:Fault>
  </soapenv:Body>
</soapenv:Envelope>

Detaljer i fejltekster

Ved nogle fejl kan faultstring indeholde dynamiske informationer som f.eks. autorisationskoder mv. Disse informationer kan anvendes af det kaldende system hvis systemet ikke selv har mulighed for at slå informationerne op i f.eks. Stamdatakomponenten. Det skal bemærkes at en fremtidig opdatering af DGWS eller en overgang til en anden standard kan betyde at disse informationer ikke længere er inkluderet i faultstring.

Test

Testdata

I modulet common ligger et antal Java Keystore filer der hver indeholder et enkelt certifikat. På testmiljøerne er nogle af disse certifikater knyttet til et antal autorisationer, således at eksemplerne kan vise forskellige anvendelser af STS'en.Medarbejdercertifikater

Funktionscertifikater

...

Virksomhedscertifikater

...

Medarbejdercertifikater

...

Øvrige certifikater

...

• • .