Introduktion

Formålet med dette dokument er at beskrive SOSI STS-implementationen. Det forudsættes at læseren har forudgående kendskabtil 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).

Arkitekturoverblik

Figur 1: STS-afhængigheder og eksterne snitflader

Eksterne snitflader

STS’ens primære funktion er udstedelse af SOSI ID-kort, som beskrevet i ”Den GodeWeb 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.

...

Service til veksling af et krypteret OIOSAML token (NemLogin token) udstedt på baggrund af et borgercertifikat til et identitytoken rettet mod anvendelse hos en given tredjepart (audience). Forespørgslen indeholder et "Claim"vedrørende borgerens cpr-nummer, som valideres op mod cpr nummer angivet i OIOSaml token.

Afhængigheder

STS’en afhænger af en række eksterne komponenter i forbindelse med udstedelse af ID-kort:

• CRL: Fulde spærrelister tilgængelige via HTTP fra certifikater.
• CRL: Hentning af intermediate- (kryds) certifikater via HTTP.
• RID-CPR: Web services for mapning af OCES2-certifikater til CPR-nummer
• PID-CPR: Web service for validering af sammenhæng mellem PID og CPR-nummer
• Database: Persistens af STS-data

• Configuration: Assembly og konfiguration af STS

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

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:

...

Figur 2: Komponenter anvendt af STS

Komponentinteraktion

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.

...

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.

Komponentsnitflader

Figur 4: Komponent-interfaces i STS

...

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:

• 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.
• 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 (se 1).
• cprhash indeholder et hash af mapningen mellem certifikat og CPR-nummer (se 2). Anvendes hvis relationerne ikke ønskes opbevaret som klartekst.
• autreg indeholder autorisationer. Krævet hvis autorisationscheck er aktivt.
• 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.

  
  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.

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

  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