Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Anchor | ||||
|---|---|---|---|---|
|
REVISION HISTORY
NUMBER | DATE | DESCRIPTION | NAME |
2.2.6 | 2015-02 |
JQ |
Contents
1 Introduktion
2 Forudsætninger
2.1 Java
2.2 JBoss
2.3 MySQL
2.4 Adgang til eksterne miljøer
2.5 Adgang til spærrelister
3 Installation
3.1 Installationsmetode
3.2 Fillokationer
3.3 MySQL
3.4 Test af installation
4 Konfiguration
4.1 JBoss
4.1.1 Admin beskyttelse
4.1.2 DataSource
4.1.3 Luna modul
4.1.4 Logning
4.2 Database
4.2.1 Audience konfiguration (ITS)
4.2.2 Audience konfiguration (ITS)
4.2.3 Audience konfiguration (Sosi2OIOSaml)
4.2.4 Autorisationer
4.3 Generel opsætning
4.3.1 Verifikation af certifikat under opstart
4.3.2 Datasource opsætning
4.3.3 Opsætning af Seal/føderation
4.3.4 CVR-RID opsætning
4.3.4.1 Fallback opsætning
4.3.5 Monitorering
4.3.6 Spærrelister
4.3.7 Autorisation
4.3.8 OIOSaml2Sosi—billetomveksling
4.3.9 Sosi2OIOSaml—billetomveksling
4.3.10 Timing
4.3.11 Timer-relaterede tasks
5 Tilpasning til produktion
...
STS kræver minimum Java 8, som kan downloades her:
http://www.oracle.com/technetwork/java/javase/downloads/
Desuden stiller SOSI biblioteket visse krav til konfigurationen af Java, som er beskrevet i "The SOSI Library: Programmers Guide" (se afsnit 3 "Set-up"). Dokumentet kan downloades sammen med SOSI biblioteket her:
https://svn.nspop.dk/public/components/seal/release-2.3.2/modules/seal/src/site/SOSI%20programmers%20guide.pdf
...
Admininistrations interfacet til STS er beskyttet af HTTP basic authentication, hvilket i JBoss angives ved at tilføje et securitydomain elememt under security-domains rod elementet i /pack/jboss/standalone/configuration/standalone.
xml
<!– STS admin login –> |
Herefter burde det være muligt at tilgå web interfacet med anvendte akkreditiver på:
http://<nsp>:8080/sts/admin
Password og bruger kan ændres i property filerne. Det er anbefalet at ændre disse ifht. hvad der følger med i leverancen.
...
STS kan integrerer med en Lunaboks på to forskellige måder. Seal integrationen til bokse købt inden 2014 og NLL integrationen til bokse købt efter 2014.
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.
Et modul oprettes på følgende sti:
/pack/jboss/modules/dk/nsi/nsp/sts/luna/main
Herunder skal passende jar-filer placeres samt filen module.xml, som skal indeholde følgende:
<?xml version="1.0" encoding="UTF-8"?> |
Dette vil fungere med Luna biblioteket, der fulgte med 2014 Luna-indkøbet. For integration op mod tidligere Lunabokse skal Luna driverne fortsat manuelt indlejres i sts.war inden deployment.
...
STS kræver adgang til en database tabel indeholdende autorisationer. Denne tabel vil typisk være oprettet og vedligeholdt via stamdata importerne i NSP.
Som default anvendes en tabel ved navn Autorisation i skemaet ejet af databasebrugeren benyttet i sts-ds.xml. Dette kan overstyres i services.xml
<bean id="authorizationService" class="dk.sosi.sts.server.service. ←StsAuthorizationService"> | ←- |
De vedlagte databasescripts opretter som udgangspunkt en valid stamdata tabel under sts-skemaet, hvilket givetvis skal ændres.
...
Det er vigtigt at føderationen sættes rigtigt op. Dels skal den rigtige føderation vælges, hhv. test eller produktion, og dels skal issuer sættes op til en fornuftig værdi i seal:sealSetupProperties. Føderationen vælges i:
seal:sosiFederation
Her kan value sættes ifht:
Table 1: Føderations opsætning
Værdi | Beskrivelse |
dk.sosi.seal.pki.SOSITestFederation | Dette er testfederationen og skal bruges i sammenhæng med test. Den skal ikke bruges i produktion. |
dk.sosi.seal.pki.SOSIFederation | Dette er produktions federationen. |
Derudover skal STS certifikatet sættes op. Der er dertil lavet et konfigurations-alias, credentialVault. Dette er i leverancens konfiguration sat til at være fil-baseret. Dette kan ses i følgende 2 elementer:
seal:credentialVault seal:fileBasedCredentialVault
I det sidste referede element kan stien samt password til det java keystore, hvori certifikatet ligger, konfigureres.
Med STS følger et testcertifikat, teststs-1.keystore, som kan benyttes til testformål.
Til produktion kan der benyttes en Luna Box baseret løsning. Dertil kan følgende element benyttes:
seal:lunaBasedCredentialVault
Der er udkommenteret to forskellige konfigurationer seal:lunaBasedCredentialVault. Den første er til tidligere Lunabokse og den anden er til nyere Lunabokse.
Hvis der for dk.sosi.seal.vault.LunaCredentialVault ønskes yderligere properties sat til konfiguration af Luna
Boxen, skal disse indsættes i seal:sealSetupProperties. Bla. kan følgende parameter tilføjes
<prop key="dk.sosi.seal.vault.LunaCredentialVault.slot">42</prop>
<prop key="dk.sosi.seal.vault.LunaCredentialVault.pwd">test1234</prop>
<prop key="dk.sosi.seal.vault.CredentialVault.alias">soso:alias_system</prop>
For dk.nsi.nsp.nll.LunaCredentialVault sættes de fleste properties direkte på bean definitionen, dog skal følgende værdi tilføjes til seal:sealSetupProperties
<prop key="sosi:cryptoprovider.sha1withrsa">LunaProvider</prop>
Når der vælges en anden vault, så skal tidligere nævnte alias opdateres. For at anvende en af de udkommenterede, så skal følgende f.eks. bruges:
<alias alias="credentialVault" name="lunaBasedCredentialVault"/>
...
Spærrelister hentes fra en CRA database der kan konfigureres i
services:certificateStatusChecker
Det er muligt at vælge om STS skal cache alle revokeringer fra CRA databasen eller om der skal laves et opslag for hvert request som STS modtager. For bedre performance anvendes CraOcesCrlServiceCacheImpl og for mindre hukommelsesforbrug anvendes CraOcesCrlServiceDbImpl.
Følgende parametre eksisterer:
Table 2: CRL setup
Parameter | Beskrivelse |
strict | Denne boolean afgører hvad der skal ske, hvis en CRL ikke findes i databasen. Hvis den sættes til true vil manglende spærreliste betyde at certifikatet er spærret. |
ttl | Angiver hvor lang tid en spærreliste kan få lov til at leve ud over den tid, der er angivet i spærrelisten selv. |
| Anchor | ||||
|---|---|---|---|---|
|
...
Til billetomveksling, her omveksling fra OIOSaml tokens til SOSI id-kort, kan der konfigures en række parametre. Disse findes her:
services:nboConfiguration
Overordnet er det:
Table 3: Billetomveksling setup
Parameter | Beskrivelse |
fuzzyTime | Gyldigheden bagud i tid af det omvekslede SOSI id-kort. |
idCardDuration | Gyldigheden fremadrettet i tid for det omvekslede SOSI id-kort. |
trustedVault | Det java keystore (vault), hvori trust til OIOSaml token etableres. Heri skal der til produktionsformål ligge certifikatet fra NemLogin IdP'en. |
allowedDriftInSeconds | Den tilladte drift i tid i sekunder ifht. NemLogin IdP'en. Dette tal angives som et ikke-negativt antal sekunder. Værdien bruges under validering af OIOSaml tokens. |
cprTrustCertificates | Angiver en liste af certifikater (SSN). Vil typisk kun indeholde et NemLog-in certifikat. Ved billetomveksling fra OIOSaml til id-kort stoler vi på cpr-numre fra disse kilder, og kan derfor undlader opslag i CVR-RID servicen for disse. Denne er indført af hensyn til enkeltmandsvirksomheder, der modtager et token med angivelse af CVR-RID, der ikke kan slås op i CVR-RID. |
I det leverede er der anvendt et keystore, som indeholder 2 certifikater: det er "det nye test NemLogin IdP" og så et yderligt, som blot er valgt arbitrært, nemlig Seal certifikatet navngivet VicValidVoces. Disse certifikater bruges til aftestning og er nødvendige for at integrationstesten er succesfuld.
...
Til billetomvekslingen fra SOSI ID-kort til OIOSaml tokens findes der 2 konfigurations muligheder udover selve servicen: en service til hentning af enkelte audience konfigurationer og så en konfigurations checker.
Konfiguration af hentning findes her:
services:iboConfigService
Her kan datasourcen samt SQL query konfigureres. Default query er
SELECT publicKey, recipientURL, includeBST, deliveryNotOnOrAfterOffset, notBeforeOffset, notOnOrAfterOffset FROM iboConfig WHERE audience = ? | ←- |
Nævnte kolonner er beskrevet i Section 4.2.3.
Konfigurations checkeren er egentlig blot en funktionalitet, der aktiveres ved opstart som normaliserer alle fundne audiences i databasen. Konfiguration heraf findes i:
services:iboConfigChecker |
Heri findes yderligere SQL queries, der kan ændres. Følgende kan tilføjes (en eller begge) til elementet: |
<property name="selectAudiences" value="select audience from iboConfig"/> | ←- |
Angivne queries er også default. |
services:iboRequestHandler |
Her er der mulighed for at sætte validateEnvelopeSignature til true eller false. Denne værdi angiver om signaturen på forespørgelser valideres eller ikke. I sammenhænge med SOSI-GW skal denne sættes til false.
Endvidere er der mulighed for at sætte checkTargetCertificate til true eller false (default er true, hvis ikke angivet).
Denne værdi angiver om det konfigurerede certifikat (benyttet til kryptering) er et validt OCES2-certifikat.
Øvrige værdier i elementet bør ikke ændres.
...
Der konfigureres 2 tidsrelaterede jobs—opsætning af disse er placeret som de 2 sidste elementer i filen timers.xml.
Table 4: Timer setup
Id | Beskrivelse |
checkDbTask | Er et job, der forespørger database/datasource med angivne query og i det angivne interval. |
checkCrlTask | Dette er et job, der sørger for at opdatere spærrelister fra CRA databasen hvis CraOcesCrlServiceCacheImpl er valgt. |
Hver enkelt timer job sættes med følgende parametre: delay tiden i millisekunder efter opstart, der ventes før jobbet udføres første gang.
oneTime boolean, der angiver om jobbet kun skal udføres en gang.
period intervallet i millisekunder jobbet udføres i medmindre oneTime er sat til true.
Den leverede konfiguration hertil er anbefaldet.
...