Page History

...

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.   **CHG-kommentar: STS står vel for 'Security Token Service ', se fx (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. **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 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 ** CHG: autentificere, ikke identificere ** sig overfor Secure Token Server autentificere sig overfor Security Token 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 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

** CHG: Tilføj noget om Det er vigtigt at forstå, at det alene 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 **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). **CHG: BRS er ikke en forretningsservice - brug et andet eksempel **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 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 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) **CHG: SSO står ellers for Single-Sign-On**/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 **CHG: ' autentificere ' ikke 'identificere' ** sig overfor denne med henblik på at få udstedt en til formålet passende sikkerhedsbillet.

...

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:

...

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.

...