Page History
...
| Table of Contents | ||
|---|---|---|
|
Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
| 1 | 6.7.2018 | KSR | Opdateret på baggrund af fuldmagtsprojektet |
| 2 | 17.9.2018 | KSR | Opdateret beskrivelser af installationer (2.5.7) |
| 3 | 5.7.2019 | JPE | Opdateret i forhold til containerization af STS. |
Introduktion
Dette Dokument beskriver installation og initiel opsætning af en STS service/server. STS installationen vil blive refereret til som service eller installation.
...
Der kræves læs-adgang til en database indeholdende opdaterede data fra NSP Certificate Revocation Authority (CRA)
Installation
STS installationen består overordnet af: konfiguration af Wildfly, deriblandt placering af tilrette konfigurations filer og deployment arkiv, og opsætning af database. STS anvender NSP's Continuous Integration og Continuous Deployment miljøer til byg og leverance af komponenten.
Installationsmetode
Ved en ny installation forventes der ikke opsætning fra en tidligere installation. Nærværende vejledning beskriver dette scenarie. Hvis der derimod opgraderes fra en tidligere version af STS kan følgende bemærkes:
- Konfigurationsfiler skal opdateres til nyeste version; stier, passwords og lignende skal med over i ny konfiguration.
- Database konfiguration kan bevares, såvidt det er muligt i forhold til skema ændringer.
- Cachen i databasen, navnligt cprhash og cprcache, kan tømmes
Fillokationer
Leverancen indeholder et sæt af filer og kataloger, som skal installeres på en NSP søjle. Her tages kun højde for opsætning til test formål, altså til testføderationen. Tilpasning til produktionmiljø beskrives senere.
Her følger en liste af filers placering:
teststs-1.keystore`, nsp-test-rid.jks, testtdc.keystore, test-new-nemLogin-idp.keystore skal i /pack/sts/
sts.war skal i /pack/wildfly/standalone/deployments.
sts-ds.xml skal i /pack/wildfly/standalone/deployments.
crasts-ds.xml skal i /packwildfly/standalone/deployments.
hele kataloget sts, hvori der findes en række xml filer, skal i /pack/wildfly/standalone/configuration.
log4j-sts.xml, log4j-nspslalog-sts.properties og nspslalog-sosists.properties skal i/pack/wildfly/standalone/configuration.
...
Jenkins
STS bygges med NSP's Jenkins server via følgende jobs:
- STS_build - Bygger koden
- STS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry.
NSP Leverandøren er selv ansvarlige for at pushe release versioner af STS til NSP Docker Registry gennem Jenkins.
Docker
STS består af et Docker images som pushes til NSP Docker Registry med følgende navne:
Docker image name |
|---|
| registry.nspop.dk/components/sts/sts |
Docker Compose
STS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/svn/components/sts/trunk/compose.
For release x.y.z af STS findes Docker Compose filerne i folderen https://svn.nspop.dk/svn/components/sts/tags/release-x.y.z/compose
En leverance af STS består af en compose folder som beskrevet ovenfor samt tilhørende tags af de fem Docker images.
Compose folderen indeholder 5 underfoldere:
Folder | Indhold |
|---|---|
| configuration | Her ligger alle de konfigurationsfiler som det forventes af driften tilretter til det anvendte miljø. Se Driftvejledningen |
| database | Her ligger alle de databasefiler som det forventes at driften lægger på en NSP database |
| development | Her ligger en Docker Compose fil til brug for udvikling. Se Guide til Udviklere. |
| test | Her ligger en Docker Compose fil der kan starte NAS2 i en standalone test konfiguration. |
| release | Her ligger den Docker Compose fil som det forventes driften anvender på både test og produktionsmiljøerne. |
Java Keystores
Der benyttes et antal java keystores. Disse beskrives i driftsvejledningen.
...
Endvidere benyttes en STS datasource til at tilgå øvrige relationelle data. Et eksempel på en sådan fil findes i releasepakken under fil navnet sts-ds.xml. Data kan inddeles i 3 "grupper", der alle kunne tilgås af den database-bruger der anvendes u i datasourcen.
Stamdata
STS har behov for læs adgang til 2 tabeller under stamdata: stamdata.autreg og stamdata.nationalRoles. Skemaerne for disse vedligeholdes af respektive importere. De to tabeller indeholder hhv. en kopi af autorisationsregisteret, samt roller importerede fra SEB (Sundhedsdatastyrelsens Elektroniske Brugerstyring). Data vedligeholdes ved skedulerede import fra eksterne kilder
| Database | Skema | Tabel | Beskrivelse | Opdateringer | SQL |
|---|---|---|---|---|---|
| Backoffice (replikeret) | stamdata | autreg | Indeholder aktuelt aktive autorisationer. | Opdateres af autorisationsimporter | Konfigurabel i services.xml |
| Backoffice (replikeret) | stamdata | nationalRoles | Indeholder roller importerede fra SEB. | Opdateres af SEB importer | Konfigurabel i services.xml |
sts databasebrugeren skal således have læs adgang til disse tabeller.
...
STS indeholder endvidere 4 tabeller med konfigurationsdata. Disse befinder sig på Backoffice og replikeres ud på de enkelte NSP-noder. Data vedligeholdes gennem separate changes:
| Database | Skema | Tabel | Beskrivelse | Opdateringer | SQL |
|---|---|---|---|---|---|
| Backoffice (replikeret) | sts_audconf | audienceConfiguration | Indeholder konfiguration af borger-billetomveksling med angivelse af audiences, og adgang til disse. beskrevet nærmere i driftsvejledningen | Via changes | Konfigurabel i services.xml |
| Backoffice (replikeret) | sts_audconf | iboConfig | Indeholder konfiguration af (Medarbejder) billet omveksling fra id-kort til OIOSaml token (sikker browseropstart). Beskrevet nærmere i driftsvejledningen. | Via changes | Konfigurabel i services.xml |
| Backoffice (replikeret) | sts_audconf | roleDefinitions | Indeholder konfiguration af gyldige nationale roller (dvs. de SEB-roller der accepteres af STS, og hvorledes disse ser ud i id-kortet) | Via changes | Konfigurabel i services.xml |
| Backoffice (replikeret) | sts_audconf | trustedCvr | Beskriver hvilke cvr-numre der har adgang til at anvende nationale roller, uden at få disse verificeret. | Via changes | Konfigurabel i services.xml |
sts databasebrugeren skal således have læs adgang til disse tabeller.
...
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). Der er tale om følgende tabel
| Database | Skema | Tabel | Beskrivelse | Opdateringer | SQL |
|---|---|---|---|---|---|
| Lokal på NSP noder | sts | cprcache | En lokal cache af svar fra opslag på cvr-rid og pid-services. | Opdateres løbende af STS | Ligger i java-koden |
sts databasebrugeren skal således have læs og skriv adgang til denne tabel
...
På andre miljøer (f.eks. staging) kan det være nødvendigt at sikre elksistens eksistens af testdata ved eksekvering af filerne: 07-sts-testdata.sql, 08-autreg-testdata.sql
Opskrift på udførelse af tests:
- svn co https://svn.nspop.dk/svn/arosiicomponents/sts/tags/release-x.7.z/code sts-x.y.z
- cd sts-x.y.z
- mvn -Pintegration verify -Dunittests.skip=true -Dsts.url=http://<nsp-host>:8080
Testen skal køre igennem uden fejl. Ved testfejl, bør undersøges om man har glemt noget i ovennævnte opsætning af testdata. Testfejl der omhandler f.eks. NboIT skyldes formentlig uoverensstemmelser i forhold til forventingen i 07-sts-testdata.sql, mens de fleste andre fejl typisk vil skyldes afvigelser i forhold til autorisationsdata..
Konfiguration
Wildfly
...
Admin beskyttelse
Det har tidligere været nødvendigt at foretage admin beskyttelse i standalone.xml. Dette er ikke længere nødvendigt.
...