Nærværende dokument henvender sig til nuværende og kommende brugere af STS (Secure Token Service).
Formålet med dokumentet er at give en forståelse af STS som produkt:
Derudover giver dokumentet et overblik over de af STS understøttede brugsscenarier med udgangspunkt i konkrete eksempler og med links til mere uddybende dokumentation af disse.
Dokumentet henvender sig primært til IT arkitekter, udviklere og forretningskonsulenter med fokus på sikkerhedsinfrastrukturer og applikationssikkerhed i forhold til National Service Platform (NSP).
Det forudsættes at læseren har en forståelse for grundlæggende koncepter og begreber indenfor applikationssikkerhed herunder certifikater (OCES), sikkerhedsprotokoler f.eks. Den Gode Webservice (DGWS), SAML og OIO IDWS og kendskab til sikkerhedsbilletter f.eks. Java Webtokens (JWT), SOSI Idkort og SAML billetter.
Dokumentet vil løbende linke til ekstern dokumentation, hvor dette er relevant.
STS er i dette dokument synonymt med en konkret service. Men STS kan også opfattes som et koncept: I denne sammenhæng står STS for Secure Token Server. **CHG-kommentar: STS står vel for 'Security Token Service', se fx https://en.wikipedia.org/wiki/Security_token_service? **
Dette er et kendt begreb indenfor IT sikkerhedsarkitekturer og beskriver en service, hvis formål er
Ideen med en Secure Token Server er, at der kan opnåes en afkobling mellem serviceanvender og serviceudbyder som illustreret i figuren nedenfor. **CHG-kommentar: Ret til 'Security Token Service' i hele dokumentet - også i figuren **
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 Token Server, 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 Token Server (se pil nr. 4 i tegningen ovenfor).
Serviceanvenderen skal identificerer ** CHG: autentificere, ikke identificere ** sig overfor Secure Token Server for at få udstedt sin sikkerhedsbillet. Secure Token Server 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 Token Server eller Identity Provider), som Secure Token Server 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 Token Server (pil nr. 1 i tegningen ovenfor).
I visse tilfælde kan en Secure Token Server kræve, at en serviceanvender specificerer, hvad sikkerhedsbilletten skal anvendes til (intended audience). Det er op til Secure Token Server at beslutte, om de medsendte claims og/eller intended audience kan opfyldes. Secure Token Server sammensætter sikkerhedsbilletten udfra serviceanvenderens identitet, eventuelle ønsker fra serviceanvender (claims+intended audience) samt prædefinerede konfigurationer. Nogle oplysninger kan Secure Token Server selv være i besiddelse af, men det er også muligt, at Secure Token Server 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 Token Server sammensætter sikkerhedsbilletten og returnerer denne til kalderen (pil nr. 3 i tegningen ovenfor).
Sikkerhedsbilletten kan indeholde en række tekniske oplysninger, der tilsammen definerer gyldigheden af sikkerhedsbilletten. Dette kunne f.eks. være:
Derudover kan sikkerhedsbilletten indeholde oplysninger (attributter) om serviceanvenderen. Dette kunne f.eks. være
** CHG: Tilføj noget om at det er service-udbyderens ansvar at foretage adgangsstyring ift. servicen og at dette kan gøres på baggrund af trust til STS og (validerede) attributter i adgangsbilletten **
Der findes i dag en række forretningsservice på NSP. Disse services dækker forskellige formål - fra datadeling via Dokumentdelingsservice (DDS) til verifikation af behandlingsrelation via Behandlingsrelationsservice (BRS). **CHG: BRS er ikke en forretningsservice - brug et andet eksempel **
Selvom formålene for NSP services er forskellige, så har de en række fællestræk f.eks. i forhold til autentifikation. 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 Security Token Service (STS). ** CHG: Eller 'SOSI-STS'? For at skelne fra en generel Security Token Service? Jeg må indrømme at jeg har aldrig har hørt begrebet 'Secure Token Server' anvendt, se også ovenstående kommentar **
Der er i skrivende stund to aktuelle sikkerhedsprotokoller i spil på NSP:
I begge tilfælde skal der i kaldet til den konkrete NSP service forevises en sikkerhedsbillet udstedt af NSPs STS. STS arbejder med følgende typer af sikkerhedsbillletter:
Som beskrevet i afsnittet ovenfor, så skal en potentiel anvender til en NSP service først integrere med STS og identificere **CHG: 'autentificere' ikke 'identificere' ** sig overfor denne med henblik på at få udstedt en til formålet passende sikkerhedsbillet.
På NSP er anvenderes autentifikation overfor STS baseret på digitale certifikater. Disse skal overholde den fælles offentlige standard for certifikater kaldet OCES: Offentlige Certifikater til Elektronisk Service. OCES certifikater indeles i fire hovedgrupper, hvoraf de tre anvendes på NSP:
Som nævnt tidligere, så er de væsentligste opgaver for STS at udstede, validere og forny/omveksle sikkerhedsbilletter. ** CHG: Ikke 'forny' kun omveksle **
I det følgende afsnit præsenteres et overblik over NSP STS:
Efterfølgende beskrives de tre overordnede anvendelsesområder, som er understøttet af STS:
De enkelte beskrivelser vil have links til mere detaljeret dokumentation.
I diagrammet nedenfor vises et overblik over STS.
De af STS udstillede services ses til venstre i tegningen. De enkelte services falder inden for de 3 overordnede områder for STS:
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? **
Service | Sikkerhedsniveau | Beskrivelse |
---|---|---|
DGWS | ||
/sts/services/NewSecurityTokenService | Niveau 3-4 | Udstedelse af SOSI Idkort. |
/sts/services/SecurityTokenService | Niveau 3-4 | Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt |
Medarbejderomveksling | ||
/sts/services/Sosi2OIOSaml | Niveau 4 | Omveksler SOSI Idkort til OIO Saml sikkerhedsbillet rettet mod et specifikt audience, f.eks. sundhed.dk. **CHG: Tilføj at billetten altid er krypter og er tænkt anvendt til SBO?** Bemærk, at det SOSI Idkort, der veksles, skal være udstedt af /sts/services/NewSecurityTokenService |
/sts/services/OIOSaml2Sosi | Niveau 5 | Omveksler OIO Saml sikkerhedsbillet til SOSI Idkort. Bemærk, at den OIO Saml sikkerhedsbillet, der veksles, skal være signeret af troværdig tredjepart (i praksis NemLog-in) |
/sts/services/BST2SOSI | Niveau 4 | Omveksler OIO Saml bootstrap token til SOSI Idkort. Bemærk, at bootstrap token skal være signeret af troværdig tredjepart: Lokal IdP, SEB eller NemLog-in |
Borgeromveksling | ||
/sts/services/Bst2Idws | Niveau 5 | Omveksler OIO Saml bootstrap token til OIO IDWS sikkerhedsbillet rettet mod et givet audience, f.eks. FMK, Dokumentdelingsservice eller MinSpærring. Bemærk, at bootstrap token skal være signeret af troværdig tredjepart: SEB eller NemLog-in |
/sts/services/JWT2Idws | Niveau 5 | Ombytter JSON Web token (JWT) til OIO IDWS sikkerhedsbillet rettet mod et givet audience, f.eks. FMK, Dokumentdelingsservice eller MinSpærring. Bemærk, at JWT tokenet skal være signeret af troværdig tredjepart (pt. en OID connector) **CHG: Ikke en 'OID connector', men en 'OpenID Connect Provider'?** |
/sts/services/JWT2OIOSaml | Niveau 5 | Omveksler JSON Web token (JWT) til OIO Saml sikkerhedsbillet rettet mod et specifikt audience, f.eks. forløbsplaner.dk **CHG: Tilføj at billetten altid er krypter og er tænkt anvendt til SBO?** Bemærk, at JWT tokenet skal være signeret af troværdig tredjepart (pt. en OID connector) **CHG: Ikke en 'OID connector', men en 'OpenID Connect Provider'?** |
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.
Som nævnt i de forgående afsnit, så identificerer ** CHG: 'autentificerer' ** 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:
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 certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLog-in.
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.
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.
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 Idkort:
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." **
Pilene på tegningen viser følgende flow:
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 )**
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):
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.
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.
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 for trustede CVR-organisationer, som selv administrere nationale roller lokalt. For disse trustes den nationale rolle der er claimet - dvs. ingen opslag i SDM**
Der henvises til STS - Guide til anvendere: DGWS for yderligere detaljer.
STS indeholder tre services til brug for medarbejderomveksling:
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øderationen, 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.
Flowet for SOSI Idkort til OIO SAML er vist i diagrammet nedenfor:
Pilene på tegningen viser følgende flow:
De to sidste typer af medarbejderomveksling veksler til et Bruger SOSI Idkort. Flowet er illustreret i diagrammet nedenfor.
Pilene på tegningen viser følgende flow:
Der henvises til STS - Guide til anvendere: Medarbejderomvekslinger for yderligere detaljer.
Der er to typer af borgeromvekslinger:
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 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.
Anvendernes interaktion med STS i forbindelse med borgeromveksling til OIO IDWS sikkerhedsbillet :
Pilene på tegningen viser følgende flow:
Der henvises til STS - Guide til anvendere: Borgeromvekslinger for yderligere detaljer.
Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads:
Omvekslingstype | Ekstra informationer |
---|---|
DGWS | Det skal oplyses, hvilket certifikat og CVR nummer, der ønskes anvendt |
Sosi2OIOSaml | Det skal oplyses hvilket audience, der ønskes vekslet til. Hvis der er tale om et nyt audience, skal der leveres følgende information:
|
OIOSaml2Sosi | Ingen ekstra informationer |
BST2SOSI |
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv. |
Bst2Idws |
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv. |
JWT2Idws |
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv. |
JWT2OIOSaml |
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv. |