...

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

    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/5b54b6f2-a137-40d7-9a2e-6417ba9f4350.html" name="test" height="460" width="800">You need a Frames Capable browser to view this content.</iframe>   

...

-- 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'@'%';

STS Deployment

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'@'%';

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.

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

...