Introduktion

Formålet med dette dokument er at beskrive SOSI STS implementationen. Det forudsættes at læseren har forudgående kendskab til STS'ens rolle - specifikt i
relation til ”Den Gode Web Service”  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

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.

Begreber

Disse begreber benyttes i snitfladerne nedenfor.

Afhængigheder

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.

Logisk arkitektur

STS består af en række del-komponenter (eller services), som konfigureres via Spring frameworket. For nærmere detaljer omkring konfigurationen henvises til installationsvejledningen. 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

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.

Figur 2: Komponenter anvendt af STS (ikke udtømmende liste)

Komponentinteraktion id-kort udstedelse

Komponenterne anvendes f.eks.  af STS ved udstedelsen af ID-kort. Sekvensdiagrammet i Figur 3 viser et typisk forløb med anvendelse af komponenterne, som STS gennemløber i forbindelse med udstedelse af MOCES signeret ID-kort, hvor resultatet er en succesfuld udstedelse af et STS signeret ID-kort.

Figur 3: STS-udstedelse af MOCES signeret ID-kort

Andre scenarier gennemløber en delmængde af de komponentinteraktioner der er illustreret i figuren. Således består udstedelsen
af skridtene:

1. Deserialisering web service request og verifikation af signatur
2. Check af ID-kort, f.eks. version og autentifikationsniveau
3. Spærrelistecheck af signerende og STS-certifikat
4. Check af certifikat til CPR-tilknytning
5. Check af autorisation knyttet til CPR
6. Signering af ID-kort med STS-certifikat
7. Serialisering af web service response

Skridt 5 og 6 foretages kun, såfremt ID-kortet er signeret med et MOCES-certifikat. Alle verifikationsskridtene kan afbryde forløbet, hvilket resulterer i, at et fejlsvar med passende information returneres til kalderen.

Diagrammerne nedenfor viser nærmere detaljer angpende henholdsvis validering af signatur, samt medarbejder validering

Figur 4: Validering af XML signatur

Figur 5: Validering af medarbejder information

Komponent interaktion omveksling fra OIOSaml assertion til id-kort

Komponentsnitflader

Figur 6: Komponent-interfaces i STS

OcesCrlService

Check af OCES-spærrelistecheck:

• isRevoked: Checker om et X509-certifikat er spærret
• getCrlTimestamp: Returnerer tidsstemplet for den underliggende spærreliste

Sker op mod en lokal kopi af revokationslister, vedligeholdt af NSP-platformen.

OcesCvrRidService

Validering eller opslag af CPR-nummer ud fra et MOCES certifikats ”subject serial number” (SSN), hvor den relevante service
afgøres udfra certifikatets issuer, f.eks. OCES1 vs OCES2:

• isRelated: Afgør om SSN og CPR-nummer hører sammen
• findRelatedCpr: Slår tilhørende CPR-nummer op ud fra SSN

OcesUUID2CPRService

Validering eller opslag af CPR-nummer ud fra et MOCES certifikats ”subject serial number” (mere specifikt medarbejder uuid'et):

• isRelated: Afgør om UUID og CPR-nummer hører sammen
• findRelatedCpr: Slår tilhørende CPR-nummer op ud fra UUID

OcesPidService

Validering af CPR-nummer ud fra et POCES-certifikats ”subject serial number” (SSN):

• isRelated: Afgør om SSN og CPR-nummer hører sammen

ProcurationService

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

• getProcurationPrivileges: Henter listen af privilegier udstedt til den aktuelle bruger (borger) fra en anden borger.
  
  

AuthorizationService

Verificerer og beriger ID-kort med autorisation ID udfra CPR-nummer:

• getAuthorizations: Finder autorisationer tilknyttet et CPR-nummer

Sker op mod en lokal kopi af autorisationsregisteret, vedligeholdt af NSP-platformen.

Datamodel

STS-anvendelse af database begrænser sig primært til læsning af konfigurationsdata og persistering af cachede værdier til (se Figur 5), og består af følgende tabeller:

• • 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 numre, der kan angive nationale roller uden at få disse validerese	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	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.

    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. For nærmere detaljer omkring konfigurations- og deploymentmuligheder henvises til installationsvejledningen [R2].

    Referencer

    [R0] Kravspecifikation Identitetsservice (version 1.3, 20. April 2006), Ribe Amt
    [R1] The SOSI Library Programmers Guide, (version 2.1, 4. Februar 2013), Lakeside
    [R2] STS Installationsvejledning (version 0.1?, ??. Februar 2013), Arosii
    [R3] Den Gode Webservice (version 1.1, 1. Juli 2008), MedCom