...

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.

Hvad er STS?

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.

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

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

Ideen med en Secure Token Server 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 serviceudbyderenEn serviceudbyder behøver således ikke at forholde sig til eller overhovedet at kende sine konkrete anvendere. 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 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 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 en tredjepart (en anden Secure Token Server), 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 medstende 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:

• Signatur: En sikkerhedsbillet skal være signeret af den udstedende Secure Token Server. Signaturen kan valideres hos serviceudbyderen ved at sammenholde den med Secure Token Servers 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.

Derudover kan sikkerhedsbilletten indeholde oplysninger (attributter) om serviceanvenderen. Dette kunne f.eks. være

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

STS på National Service Platform (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 SSO til sundhed.dk eller forløbsplaner.dk)

Anvendelse af STS på NSP

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

Anvenderes På NSP er anvenderes autentifikation overfor STS er 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:

...

I det følgende afsnit præsenteres et overblik over NSP STS:

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

...