...

Formålet med dette dokument er at beskrive SOSI STS implementationen. Det forudsættes Det forudsættes at læseren har forudgående kendskab til STS'ens rolle - specifikt i
relation til ”Den Gode Web Service”  og (DGWS) og de standarder den baserer sig på.

...

På NSP anvendes id-kort som single sign-on mekanisme til at autentificere anvendere op mod platformens services. I andre sammenhænge som f.eks. på sundhed.dk eller borger.dk anvendes den fælles offentlig brugerstyring (Nem-Login). STS'en tilbyder billetomveksling for at lette integration mellem disse, så anvendere nemt kan kalde services på tværs af NSP og andre systemer. 

Anvenderes tilgang til STS vil ofte være med hjælp fra Seal.Java eller Seal.NET, som er biblioteker der bl.a. hjælper til med at understøtte brugen af DGWS og håndtere sikkerhedsaspekterne.

...

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 STS en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation i NSP-komponenterne. 

Dette 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.

Ingen STS kræver ingen whitelisting og ingen specifikke WSDL'er eksisterer for STS'ens servicesSTS kræver ingen whitelisting.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/24e0d66c.html" name="test" height="1050" width="900">You need a Frames Capable browser to view this content.</iframe>   

...

STS består af en række del-komponenter (eller services), som konfigureres via Spring-frameworket. Komponenterne indkapsler følgende funktionalitet:

• Crl: Spærreliste kontrol af OCES certifikater
• Acl: Check for adgang til udstedelse ID-kort (benyttes ikke pt)
• Cpr: CPR opslag ud fra OCES-medarbejdercertifikat eller borgercertifikat
• Authorization: Verifikation af autorisation id ud fra CPR Fuldmagt og den fællesoffentlige fuldmagtsløsning.

En væsentlig komponent for STS er SOSI Seal biblioteket, der indtager en central rolle i forbindelse med udstedelse af ID-kortet. Seal anvendes som et tredjeparts bibliotek af STS.

Image Added

Figur 1: Komponenter anvendt af STS (ikke udtømmende liste)Figur 1: STS-afhængigheder og eksterne snitflader

Oversigt over snitflader og adgang

Følgende er en oversigt over STS snitflader og kravene til adgang til disse:

• NewSecurityTokenService -- Udstedelse af STS-signeret id-kort. Erstatter samtidig NameId til et kanonisk format (nødvendigt hvis id-kortet skal veksles til OIOSaml). SOSI Seal biblioteket benyttes af STS til serialisering/deserialisering af web service kaldet samt signering af udstedte ID-kort.
• SecurityTokenService -- Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt.
• Sosi2OIOSaml -- Ombytter STS-signeret id-kort fra SOSI ID-kort til OIOSAML assertion (NemLogin token) rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af NewSecurityTokenService.
• OIOSaml2Sosi -- Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart (nemlogin).
• Bst2Idws -- 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).
• JWT2Idws -- 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).

Figur 2: STS-afhængigheder og eksterne snitflader

Disse begreber benyttes i snitfladerne:

...

STS’en afhænger af en række eksterne komponenter i forbindelse med udstedelse af og omveksling af billetter. Afhængigheder i parantes anvendes kun i visse scenarier: 

Afhængigheder i parantes anvendes kun i visse scenarier.

Logisk arkitektur

...

• Crl: Spærreliste kontrol af OCES certifikater
• Acl: Check for adgang til udstedelse ID-kort (benyttes ikke pt)
• Cpr: CPR opslag ud fra OCES-medarbejdercertifikat eller borgercertifikat
• Authorization: Verifikation af autorisation id ud fra CPR
• Fuldmagt

...

Image Removed

...

Komponentinteraktion id-kort udstedelse

...

CREATE TABLE iboConfig (
audience VARCHAR(255) NOT NULL,
publicKey TEXT NOT NULL,
recipientURL VARCHAR(255) NOT NULL,
includeBST BOOL NOT NULL,
deliveryNotOnOrAfterOffset BIGINT NOT NULL,
notBeforeOffset BIGINT NOT NULL,
notOnOrAfterOffset BIGINT NOT NULL,
idCardMaxAgeMins BIGINT,
KEY audience (audience)
)

Tabel: trustedCvr

-- new table to hold trustedCvr for national roles
USE sts_audconf;

...