Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootSikkerhedsservices (STS) - Leverancebeskrivelse
firsttabsikkerhedsservices (STS)
includeroottrue


Excerpt
hiddentrue

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 kendskabtil STS’ens kendskab til STS'ens rolle - specifikt i relation til ”Den Gode Web Service” [R3] (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).


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


Table of Contents
outlinetrue

Arkitekturoverblik

Image Removed

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.

Sekundært udstiller STS’en administrativ funktionalitet, det vil sige operationel status, ACL konfiguration, log adgang og cache kontrol, gennem et simpelt webbaseret interface.

Code Block
languagejava
SecurityTokenService

Service til udstedelse af SOSI ID-kort. Anvendelsen af STS er beskrevet i ”Den GodeWeb 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]).

Code Block
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]).

Code Block
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]).

Code Block
Bst2Idws

Service til veksling af et OIOSAML bootstraptoken (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 med anvendelse af pid-cpr service hos Nets

Code Block
Saml2Idws

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 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)


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

Oversigt over snitflader og adgang

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

...

Configuration: Assembly og konfiguration af STS

af og omveksling af billetter. Afhængigheder i parantes anvendes kun i visse scenarier: 


...

AfhængighedBeskrivelseSecurityTokenServiceOIOSaml2SosiSosi2OIOSamlBst2IdwsBST2SOSIJwt2Idws
CRASpærrelister tilgængelige på NSP platformen, indlæst via et baggrundsjobXXXXX
KrydscertifikaterHentes via HTTP fra internettetXXXXX
STS databaseKonfiguration og lokal cache af CPRXXXXX
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:

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

Image Removed

Figur 2: Komponenter anvendt af STS

Komponentinteraktion

...

XXXXX
AutorisationerIndlæses fra autorisationsregisterXX

X
Nationale roller (SEB)
XX

X
RID2CPRVerifikation af medarbejderes CPR nr. Hentes fra internet fra central traffic manager(X)(X)

(X)
UUID2CPRVerifikation af medarbejderes CPR nr. Hentes fra internet fra central traffic manager



(X)
PID2CPRVerifikation af borgeres CPR nr. Hentes fra internet fra central traffic manager


X

FuldmagtsserviceVerifikation om fuldmagt til at agere på vegne af anden borger


(X)

IDSASSløring af sundhedsfaglig over for et CPR-NR.


(X)
(X)
PersoninformationIntern service til henting af stamdata


(X)
(X)


HTML
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-24e0d66c.html" name="test" height="730" 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.

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

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.

Image RemovedImage Added

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

...

  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. ACL-verifikation blacklisting 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.

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


Image Added

Figur 4: Validering af XML signatur

Image Added

Figur 5: Validering af medarbejder information

Komponent interaktion omveksling fra OIOSaml assertion til id-kort

Image Added


Snitflader

BegrebForklaring
AnvendersystemDet IT-system som anvender en STS snitflade
BrugerDen bruger som via et klient IT-system anvender STS
TrustHvem stoler vi på som signerende part på en indgående billet.
ModtagerHvilke systemer kan anvende den billet der udstedes af STS.



SnitfladeSnitfladeAnvendersystemBrugerTokensTrustModtager

/sts/services/SecurityTokenService

/sts/services/NewSecurityTokenService

WS-Trust 1.2 (DGWS)Alle som har netværksmæssig adgangSystem eller medarbejder

Input: Selvsigneret id-kort

Output: STS signeret id-kort

Indgående id-kort skal være signeret af "brugeren selv".Alle DGWS-services
/sts/services/OIOSaml2SosiWS-Trust 1.4 (OIO-IDWS 1.0)

Alle som har netværksmæssig adgang.

Dele af SOAP besked skal være signeret med system-certifikat

Alle medarbejdere

Input: OIO-Saml assertion 

Output: STS signeret id-kort

OIOSaml assertion skal være signeret af trusted part.


Alle DGWS-services
/sts/services/Sosi2OIOSamlWS-Trust 1.4 (OIO-IDWS 1.0)

Alle som har netværksmæssig adgang

Dele af SOAP besked kan være signeret med system-certifikat (verificeres ikke pga DCC/Gateway)

Alle medarbejdere

Input: STS signeret id-kort

Output: OIO-Saml assertion

Id-kort skal være signeret af STS (udstedt af /NewSecurityTokenService)

Modtager-system skal være konfigureret (i tabellen iboConfig).

/sts/services/BST2SOSIWS-Trust 1.4 (OIO-IDWS 1.0)Alle som har netværksmæssig adgangAlle medarbejdere

Input: OIO-Saml bootstrap token

Output: STS signeret id-kort

Bootstrap token skal være signeret af trusted part.

Lokal IdP eller SEB 

Alle DGWS-services
/sts/services/Bst2IdwsWS-Trust 1.4 (OIO-IDWS 1.0)

Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration).

Dele af SOAP besked skal være signeret med denne nøgle.

Alleborgere

Input: OIO-Saml bootstrap token

Output: IDWS (1.0) token.

Bootstrap token skal være signeret af trusted part.

I praksis SEB

Modtager-system skal være konfigureret (i tabellen audienceConfiguration).
/sts/services/JWTIdwsWS-Trust 1.4 (OIO-IDWS 1.0)

Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration).

Dele af SOAP besked skal være signeret med denne nøgle.

Alleborgere

Input: JWTsigneretafOpenId connector

Output: IDWS (1.0) token.

JWT skal være signeret af trusted part (i test-jwt-idp-trust.jks). kid skal pege på det rigtige alias i denne.

Issuer skal være konfigureret i services.xml

Modtager-system skal være konfigureret (i tabellen audienceConfiguration).

JWT suport skal være aktiveret (i tabellen audienceConfiguration)

/sts/services/JWT2OIOSamlWS-Trust 1.4 (OIO-IDWS 1.0)

Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration).

Dele af SOAP besked skal være signeret med denne nøgle.

Alleborgere

Input: JWTsigneretafOpenId connector

Output: OIO-Saml assertion

JWT skal være signeret af trusted part (i test-jwt-idp-trust.jks). kid skal pege på det rigtige alias i denne.

Issuer skal være konfigureret i services.xml

Modtager-system skal være konfigureret (i tabellen audienceConfiguration).

JWT suport skal være aktiveret (i tabellen audienceConfiguration)


Gliffy Diagram
macroIdd8067d96-d999-439c-a123-ff5b8a754fd4
displayNamests-afhængigheder
namests-arkitektur
pagePin3

Figur 2: STS-afhængigheder og eksterne snitflader


  • 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 rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af NewSecurityTokenService.
  • OIOSaml2Sosi -- Ombytter OIOSaml token til signeret id-kort. Token skal være signeret af troværdig tredjepart.
  • 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.
  • 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).

Komponentsnitflader

...

Image Removed

Gliffy Diagram
macroId65259668-7835-45dd-a5a1-1136085f0aeb
displayNamests-komponentsnitflader
namests-komponentsnitflader
pagePin2

Figur 6Figur 4: Komponent-interfaces i STS

...

Code Block
OcesCvrRidService

Validering eller oslag 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
Code Block
OcesPidService
OcesUUID2CPRService

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

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

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 - bruges ikke mere
  • isBlackListed: Afgør om certifikat information og system navn er black listed

...

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

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

Hentning af fuldmagter fra 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.

Code Block
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:

  • 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
    • SkemaTabelBeskrivelseBenyttes pt
      STS (backoffice)iboConfigindeholder audience specifik konfiguration for SOSI ID-kort til OIOSAML omvekslingJa
      STS (backoffice)audienceConfigurationindeholder konfiguration vedrørende billetomveksling fra bootstrap token til IDWS token og fra JWT token til OIOSaml tokenJa
      STS (backoffice)roleDefinitionsIndeholder opsætning af gyldige nationale roller, og hvorledes disse repræsenteres i id-kort og i SEBJa
      STS (backoffice)

      authorizationDefinitions

      Indeholder valide uddannelseskoder. Primært 4 cifre, men kan også indeholde bogstaver.Ja
      STS (backoffice)trustedCvrIndeholder en liste af CVR numre, der kan angive nationale roller uden at få disse valideret.Ja
      STS (lokal)cprcache
    • indeholder relationer mellem certifikat og CPR-nummer. Anvendes hvis deploymiljøet er godkendt til opbevaring af relationen i klartekst (
  • se 1
    • Nødvendig hvis ikke CPR web servicen altid skal kaldes med manglende CPR i ID-kort).Ja
      STS (lokal)cprhashindeholder et hash af mapningen mellem certifikat og CPR-nummer
  • (se 2). Anvendes
    • . Oprindeligt tænkt anvendt 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.

    Image RemovedFigur 5: STS-datamodel
    • . 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)whitelistindeholder 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)blacklistindeholder information (X509 certifikat subject serial number), der anvendes til at blokere for udstedelse af ID-kort for specifikke certifikater.Nej
      SDMautregIndeholder aktuelle autorisationskoder for autoriserede sundhedsfaglige medarbejdere. Vedligeholdes af Autorisations importerenJa
      SDMnationalRolesIndeholder roller importerede fra SEBJa
      CRAcrlIndeholder et antal spærrelister incl. metadata omkring seneste hentning af disseJa
      CRArevoked

      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.



HTML
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-5b54b6f2-a137-40d7-9a2e-6417ba9f4350.html" name="test" height="510" 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:
--------------------------------------
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)

DB: sts_audconf

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(128) 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;

DROP TABLE IF EXISTS roleDefinitions;
CREATE TABLE roleDefinitions (
source VARCHAR(255) NOT NULL,
externalName VARCHAR(255) NOT NULL,
code VARCHAR(255) NOT NULL,
value VARCHAR(255)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

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.

STS kan integrere med en Lunaboks på to forskellige måder. Seal integrationen til bokse købt inden 2014 (generation 4) og NLL integrationen til bokse købt efter 2014 (generation 5). Det forventes at den JBoss som STS deployes på indeholder et jboss-modul med navnet dk.nsi.nsp.sts.luna. STS afhænger af eksistensen af et sådant modul. Modulet kan være tomt - men skal, såfremt man anvender nyere Lunabokse, ændres til at indeholde Luna biblioteker (driver). Herved kan disse deployes/opgraderes uafhængig af STS.

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