STS Designdokument. STS Designdokument

Transkript

1 STS Designdokument i STS Designdokument

2 STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME N

3 STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik Eksterne snitflader Afhængigheder Logisk arkitektur Komponent interaktion Komponent snitflader Datamodel 5 5 STS Deployment 6 6 Referencer 6

4 STS Designdokument 1 / 7 1 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 [R3] 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). 2 Arkitekturoverblik Figur 1: STS afhængigheder og eksterne snitflader 2.1 Eksterne snitflader STS ens primære funktion er udstedelse af SOSI ID-kort, som beskrevet i Den Gode Web Service (se afsnittet STS-Kommunikation i [R3]). Til serialisering/deserialisering og signering af web service kald anvendes STS SOSI Seal biblioteket, som skitseret i The SOSI Library Programmers Guide (se Use case 3: How to issue an ID-card i [R1]). Desuden tilbyder STS en web services til veksling til og fra SOSI ID-kort. Sekundært udstiller STS en administrativ funktionalitet, det vil sige operationel status, ACL konfiguration, log adgang og cache kontrol, gennem et simpelt webbaseret interface. SecurityTokenService Service til udstedelse af SOSI ID-kort. Anvendelsen af STS er beskrevet i Den Gode Web Service (se afsnittet STS-Kommunikation i [R3]). SOSI Seal biblioteket benyttes af STS til serialisering/deserialisering af web service kaldet samt signering af udstedte ID-kort. For nærmere information om anvendelsen af denne service se "Use case 1: How to authenticate an ID-card"i The SOSI Library Programmers Guide ([R1]). IdentityTokenService Service til veksling af SOSI ID-kort til OIOIDWS-H Identity Token (se [R4]). For nærmere information om anvendelsen af denne service se "Use case 5: Request an Identity token from a STS"i The SOSI Library Programmers Guide ([R1]).

5 STS Designdokument 2 / 7 OIOSaml2Sosi Service til veksling af OIOSAML assertion (NemLogin token) til SOSI ID-kort. For nærmere information om anvendelsen af denne service se "Use case 9: Exchange an OIOSAML assertion to an IDCard at a STS"i The SOSI Library Programmers Guide ([R1]). -Sosi2OIOSaml+ Service til veksling af SOSI ID-kort til OIOSAML assertion (NemLogin token). For nærmere information om anvendelsen af denne service se "Use case 11: Exchange an IDCard to an encrypted OIOSAML assertion at a STS"i The SOSI Library Programmers Guide ([R1]). 2.2 Afhængigheder STS en afhænger af en række eksterne komponenter i forbindelse med udstedelse af ID-kort: OcesCRL: Fulde spærrelister tilgængelige via HTTP fra certifikater. OcesCPR: Web services for mapning af OCES1 og OCES2 certifikater til CPR-nummer Database: Persistens af STS data Configuration: Assembly og konfiguration af STS Keystore: Indeholder certifikat og nøgler for føderationen 3 Logisk arkitektur STS består af en række komponenter (eller services), som konfigureres via Spring. For nærmere detaljer omkring konfigurationen henvises til installationsvejlednignen (se [R2]). Komponenterne indkapsler følgende funktionalitet: Crl: Spærreliste kontrol af OCES certifikater Acl: Check for adgang til udstedelse ID-kort Cpr: CPR opslag ud fra OCES-medarbejdercertifikat Authorization: Verifikation af autorisation id ud fra CPR En væsentlig komponent for STS er SOSI Seal biblioteket, der indtager en central rolle i forbindelse med udstedelse af ID-kortet (se også Figur 3). Seal anvendes som et tredjeparts bibliotek af STS.

6 STS Designdokument 3 / 7 Figur 2: Komponenter anvendt af STS 3.1 Komponent interaktion Komponenterne anvendes 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

7 STS Designdokument 4 / 7 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. Verifikation ACL (black listing af certifikater) 5. Check af certifikat til CPR tilknytning 6. Check af autorisation knyttet til CPR 7. Signering af ID-kort med STS certifikat 8. 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. 3.2 Komponent snitflader Figur 4: STS komponent interfaces OcesCrlService Check af OCES spærrelistecheck: isrevoked: Checker om et X509 certifikat er spærret getcrltimestamp: Returnerer tidsstemplet for den underliggende spærreliste Anvender Seal bibliotekets implementation der bestemmer spærrelistens placering udfra certifikatet. OcesCvrRidService Opslag af CPR-nummer ud fra et OCES 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

8 STS Designdokument 5 / 7 findrelatedcpr: Slår tilhørende CPR-nummer op ud fra SSN AclService Gennem denne komponent afgøres på baggrund af certifikat information og system navn om ID-kort kan udstedes. Udstiller følgende operationer: iswhitelisted: Afgør om certifikat information og system navn er white listed isblacklisted: Afgør om certifikat information og system navn er black listed Bemærk at operationerne ikke er gensidig udelukkende. Det er således muligt både at være white listed og black listed, og det er op til kalderen af afgøre hvilken præcedens operationerne skal have. I standardkonfigurationen anvendes white list checket ikke, men kan eksplicit slås til. AuthorizationService Verificerer og beriger ID-kort med autorisation ID udfra CPR-nummer: getauthorizations: Finder autorisationer tilknyttet et CPR-nummer 4 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: whitelist indeholder information (CVR-nummer og system navn), der anvendes til at at give systemer adgang til udstedelse af ID-kort. Kræves kun hvis whitelisting er aktivt. blacklist indeholder information (X509 certifikat subject serial number), der anvendes til at blokere for udstedelse af ID-kort for specifikke certifikater. cprcache indeholder relationer mellem certifikat og CPR-nummer. Anvendes hvis deploymiljøet er godkendt til opbevaring af relationen i klartekst 1. cprhash indeholder et hash af mapningen mellem certifikat og CPR-nummer 2. Anvendes hvis relationerne ikke ønskes opbevaret som klartekst. autreg indeholder autorisationer. Krævet hvis autorisationscheck er aktivt. audienceconfiguration indeholder konfiguration til ID-kort veksling per konfigureret audience. iboconfig indeholder audience specifik konfiguration for SOSI ID-kort til OIOSAML omveksling. 1 Nødvendig hvis ikke CPR web servicen altid skal kaldes med manglende CPR i ID-kort 2 SHA-256 af X509 certifikatets serial number og tilhørende CPR-nummer

9 STS Designdokument 6 / 7 Figur 5: STS datamodel 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. 5 STS Deployment STS applikationen er en J2EE web applikation, som deployes til driftsmiljøerne som et WAR-arkiv. Applikationen deployeres sammen med konfigurationsartefakter, som 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]. 6 Referencer [R0] [R1] [R2] Kravspecifikation Identitetsservice (version 1.3, 20. April 2006), Ribe Amt The SOSI Library Programmers Guide, (version 2.1, 4. Februar 2013), Lakeside STS Installationsvejledning (version 0.1?,??. Februar 2013), Arosii

10 STS Designdokument 7 / 7 [R3] [R4] Den Gode Webservice (version 1.1, 1. Juli 2008), MedCom Veksling til OIOIDWS-H Identity Tokens, (version 0.3, 13. Juli 2011), Lakeside