...

Introduktion

Formålet med dette dokument design- og arkitekturbeskrivelse er at beskrive SOSI STS implementationen. Detaljeringsgraden henvender sig til læseren der har behov for en overordnet introduktion til implementationen.

Det forudsættes at læseren har forudgående kendskab til STS'ens rolle - specifikt i relation til ”Den Gode Web Service” (DGWS) og de standarder den baserer sig på.Detaljeringsgraden henvender sig til læseren der har behov for en overordnet introduktion til implementationen, herunder systemkontekst (afsnit 2), opdeling
i komponenter (afsnit 3) og datamodellen (afsnit 4). Desuden berøres deployment afhængigheder (afsnit 5).

Arkitekturoverblik

Security Token Service (STS) er en fælles komponent, som kan udstede adgangsgivende billetter på baggrund af OCESSecurity Token Service (STS) er en fælles komponent, som kan udstede adgangsgivende billetter på baggrund af OCES-certifikater. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider).

På NSP anvendes id-kort som single sign-on mekanisme til at autentificere anvendere op mod platformens services. STS'en tilbyder billetomveksling for at lette integration mellem disse, så anvendere nemt kan kalde services på tværs af NSP og andre systemer. 

Arkitekturoverblik

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

...

STS 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: 

<iframe 

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

...

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

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.

...

...

• 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 assertion 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 OIOSaml 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).

...

ProcurationService

Hentning af fuldmagter fra NemLog-In fuldmagtsservicenfra fuldmagtsservicen. Validering af CPR-nummer ud fra en borgers CPR-nummer:

...

• • Skema	Tabel	Beskrivelse	Benyttes pt
    STS (backoffice)	iboConfig	indeholder audience specifik konfiguration for SOSI ID-kort til OIOSAML omveksling	Ja
    STS (backoffice)	audienceConfiguration	indeholder konfiguration vedrørende billetomveksling fra bootstrap token til IDWS token og fra JWT token til OIOSaml token	Ja
    STS (backoffice)	roleDefinitions	Indeholder opsætning af gyldige nationale roller, og hvorledes disse repræsenteres i id-kort og i SEB	Ja
    STS (backoffice)	authorizationDefinitions	Indeholder valide uddannelseskoder. Primært 4 cifre, men kan også indeholde bogstaver.	Ja
    STS (backoffice)	trustedCvr	Indeholder en liste af cvr CVR numre, der kan angive nationale roller uden at få disse valideresevalideret.	Ja
    STS (lokal)	cprcache	indeholder relationer mellem certifikat og CPR-nummer. Anvendes hvis deploymiljøet er godkendt til opbevaring af relationen i klartekst (Nødvendig hvis ikke CPR web servicen altid skal kaldes med manglende CPR i ID-kort).	Ja
    STS (lokal)	cprhash	indeholder et hash af mapningen mellem certifikat og CPR-nummer. Oprindeligt tænkt anvendt hvis relationerne ikke ønskes opbevaret som klartekst. Ikke længere muligt, idet der er behov for at kunne tilføje cpr nummer til et id-kort uden dette er angivet i input.	Nej
    STS (lokal)	whitelist	indeholder information (CVR-nummer og system navn), der anvendes til at at give systemer adgang til udstedelse af ID-kort. Benyttes ikke længere.	Nej
    STS (lokal)	blacklist	indeholder information (X509 certifikat subject serial number), der anvendes til at blokere for udstedelse af ID-kort for specifikke certifikater.	Nej
    SDM	autreg	Indeholder aktuelle autorisationskoder for autoriserede sundhedsfaglige medarbejdere. Vedligeholdes af Autorisations importeren	Ja
    SDM	nationalRoles	Indeholder roller importerede fra SEB	Ja
    CRA	crl	Indeholder et antal spærrelister incl. metadata omkring seneste hentning af disse	Ja
    CRA	revoked	Indeholder replika af en given spærreliste indeholdende aktuelt revokerede certifikater Hvis en CRL er udstedt af en CA og denne CA trækkes tilbage, så vil alle dens rækker i revoked blive slettet og en enkelt række med NULL i serialnumber vil blive oprettet. Et certifikat skal derfor betragtes som trukket tilbage hvis dets CRL enpoint findes i crl og dets serienummer findes i revoked eller der findes en række med serienummeret NULL.	Ja

    
    

    Databasemodellen er simpel og indeholder ingen bindinger til specifikke databaser. Tabellerne cprhash og cprcache fungerer som en simpel cache for CPR-opslag, og repopuleres automatisk, hvorfor rækkerne kan slettes efter behov.

...

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-5b54b6f2-a137-40d7-9a2e-6417ba9f4350.html" name="test" height="460510" width="800">You need a Frames Capable browser to view this content.</iframe>   

...

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Entitetsindhold

audienceConfiguration

DB: sts_audconf

Indeholder konfiguration af borger-billetomveksling med angivelse af audiences, og adgang til disse. Bruges også til at sætte sløring (kald til IDSAS) for et givet audience.

Objektet indeholder informationen:
Objektet indeholder informationen:
--------------------------------------
audience
attribute
attribute_value

authorizationDefinitions

DB: sts_audconf

Objektet indeholder informationen:
--------------------------------------
role

cprcache

DB: sts

cprcache fungerer som en simpel cache for CPR-opslag, og repopuleres automatisk, hvorfor rækkerne kan slettes efter behov.

STS indeholder indeholder endelig en cache at mapningen fra SubjectSerialNumber til cpr nummer for medarbejdere og borgere. Dvs. SubjectSerialNumber kan enten være et PID eller et cvr-rid. Tabellen ligger lokalt på de enkelte NSP-noder uden replikering. Data opdateres automatisk af STS og data vil altid kunne slettes unden funktionel effekt (vil dog have negativ, midlertidig effekt på performance).

iboConfig

DB: sts_audconf

Indeholder konfiguration af (Medarbejder) billet omveksling fra id-kort til OIOSaml token (sikker browseropstart)

Objektet indeholder informationen:
--------------------------------------
audience
publicKey
recipientURL
includeBST
deliveryNotOnOrAfterOffset
notBeforeOffset
notOnOrAfterOffset
idCardMaxAgeMins

trustedCvr

DB: sts_audconf

Objektet indeholder informationen:
--------------------------------------
cvr
endpoint

NSP Keystore (Luna box)

Indeholder certifikat og nøgler for føderationen, samt trustede 3. parter der kan foretages billetomveksling fra.

Placeret i dedikeret LUNA boks for maximim sikkerhed

roleDefinitions

Indeholder opsætning af gyldige nationale roller, og hvorledes disse repræsenteres i id-kort og i SEB (Sundhedsvæsenets Elektroniske Brugerstyring)

...

Objektet indeholder informationen:
--------------------------------------
source -- Hvem har udstedt rollen, ex: 'NationalFederation'
externalName -- rollenavn, ex: 'nspSundAssistR1'
code -- rolle kode, ex: '41001'
value -- rolle navn, ex: 'SundAssistR1'

Tabelbeskrivelser

Tabel: audienceConfiguration

DB: sts_audconf

CREATE TABLE audienceConfiguration (
audience VARCHAR(255) NOT NULL,
attribute VARCHAR(50128) NOT NULL,
attribute_value VARCHAR(4095));
CREATE UNIQUE INDEX audienceConfiguration_uniq ON audienceConfiguration (audience, attribute);

Tabel: authorizationDefinitions

-- new table to hold authorizationDefinitions

USE sts_audconf;
CREATE TABLE authorizationDefinitions (
role VARCHAR(4) NOT NULL)
ENGINE=InnoDB DEFAULT CHARSET=utf8;

Tabel: cprcache

CREATE TABLE cprcache (
ssn VARCHAR(64) NOT NULL,
cpr VARCHAR(16) NOT NULL,
createdDate datetime);
CREATE UNIQUE INDEX cprcache_ssn ON cprcache (ssn);

Tabel: iboConfig

DB: sts_audconf

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;

CREATE TABLE trustedCvr (
cvr VARCHAR(8) NOT NULL,
endpoint VARCHAR(64) NOT NULL,

roleValue VARCHAR(64)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

create unique index trustedCvr_uniq on trustedCvr (cvr, endpoint);

Tabel: roleDefinitions

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

...

GRANT ALL ON sts_audconf.roleDefinitions TO 'sts'@'%';

Sløring af sundhedsfaglige - IDSAS

STS'en kalder IDSAS for at finde ud af, om en given sundhedsfaglig ønsker at blive sløret over for et givet CPR-NR. Der er lavet en integration til IDSAS i STS'en, som laver et internt SOAP-kald til IDSAS, for at hente evt. aktive sløringer.

Disse sløringer sættes på billetten som STS returnerer. 

Sløring sker kun for de audiences som sløring er konfigureret for.

Claims om værge og forældremyndighed - Subject Relations

Der er lave en integration til personinformation-servicen, hvor man kan validere claims omkring værgemål og forældremyndighed. Hvis et claim er opfyldt, sættes det på billetten som en Subject Relation.

Kravet er, at der kun må være én sådan relation på billetten af gangen, da billetten skal være så smal som muligt.

Subject relations vil kun blive udfyldt på billetten, hvis der er gyldige claims i sikkerhedsanmodningen.

STS Deployment

STS-applikationen er en JEE web applikation, som afvikles i driftsmiljøerne som en docker container. Containeren afvikles med en række konfigurationsfiler mounted ind i containeren, disse bestemmer STS runtime egenskaber, herunder føderation (test eller produktion), eksterne services og konfiguration af logning.

...