Contents
1 Introduktion
2 Konfigurations opdateringer
2.1 Dynamisk konfiguration. Billetomveksling fra ID-kort til OIOSaml assertion
2.2 Dynamisk konfiguration. Billetomveksling fra Bootstraptoken til identitytoken (Bst2Idws)
3 SLA logning
4 Monitorering
5 Services
6 Certifikater

Anchor
_Toc7249 _Toc7249

Introduktion

Dette dokument indeholder en vejledning til driften af SOSI-STS version 2.4.1.

Anchor
_Toc7250 _Toc7250

Konfigurations opdateringer

Ud over statisk konfiguration, som er beskrevet i installationsvejledning, så findes der desuden følgende områder som kan konfigureres dynamisk:

Anchor
_Toc7251 _Toc7251

Dynamisk konfiguration. Billetomveksling fra ID-kort til OIOSaml assertion.

Omveksling fra ID-kort til OIOSaml assertions kræver konfiguration gemt i databasen i tabellen sts_audconf.iboConfig; disse er:

• audience identifikation af modtagersystemet som en URI, der skal være på normalform jvf. tidligere afsnit.
• publicKey den offentlige nøgle som anvendes til kryptering af den omvekslede token. Bemærk at indholdet er tilgivende overfor line-breaks og whitespaces, så der kan formateres valgfrit.
• recipientURL den URL hvor modtagersystemet kan nåes på.
• includeBST om ID-kort/bootstrap token skal inkluderes i den svarede assertion.
• deliveryNotOnOrAfterOffset det offset i tid fra omvekslingstidspunktet, der angiver hvornår det udstede må anvendes af modtagersystemet.
• notBeforeOffset offset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion.
• notOnOrAfterOffset offset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion.

I Installationsvejledningen er der beskrevet hvordan konfigurationen udvides.
Konfiguration i database er altid den gældende—det er ikke nødvendigt at genstarte før ændringer træder i kraft.

Anchor
_Toc7252 _Toc7252

Dynamisk konfiguration. Billetomveksling fra Bootstraptoken til identitytoken (Bst2Idws).

Omveksling fra Bootstrap token til identitytoken (også kaldet webapotek løsning) benyttes til at veksle et Bootstraptoken udstedet af NemLog-in på vegne af en borger, til et identitytoken, der kan benyttes til login i FMK-online (og senere formentligm også MinLog2).
Denne kræver ligeledes konfiguration i databasen, i tabellen sts_audconf.audienceConfiguration; Bemærk at tabellen tidligere har været brugt til andet formål.
Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value.
For et givet audience (f.eks. https://fmk) kan der være følgende indgange

• lifetime. Angiver gyldighed af det udstedte token, f.eks. 3600 (s).
• certificate.xxx. Angiver ssn for et certifikat der har mulighed for at benytte servicen. Dette certifikat benyttes af anvender til at signere hele beskeden (beskeden har så bl.a. en Assertion signeret af NemLog-in).

Der kan være et vilkårligt antal certificate.xxx indgange. Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen.
Konfiguration i database er altid den gældende—det er ikke nødvendigt at genstarte før ændringer træder i kraft.

Anchor
_Toc7253 _Toc7253

SLA logning

Følgende tabel viser STS'ens sla logpunkter samt tilhørende navn. De enkelte logpunkter beskrives i detaljer i det følgende.
Table 1: SLA log punkter

Anchor
_Toc7254 _Toc7254

Monitorering

Der findes en check URL, som afgører om servicen som helhed kan svare. Der skelnes ikke mellem de enkelte dele af STS'en. Adressen er:
http://<sts-host>:<port>/sts/checkstatus
Ved fejl, vil HTTP returkoden være 500. Ellers vil den være 200.
Følgende aspekter af STS'en checkes:

1. STS certifikatets gyldighed
2. Adgang til databasen

Derudover udskrives en række statitiske oplysninger. Her er et eksempel:
Version: 2.4.1
Local time: Mon Nov 05 10:35:49 GMT+01:00 2012
Started: Mon Nov 05 10:27:07 GMT+01:00 2012
Last transaction: never
Last issued: never
Sts certificate, valid from: Thu Sep 01 14:40:08 GMT+01:00 2011 Sts certificate, valid until: Sun Sep 01 15:10:08 GMT+01:00 2013
Sts certificate valid: OK
Requests, 24h: 0
Requests, total: 0
Failed requests, 24h: 0
Failed requests, total: 0
Response time, avg 24h: 0 ms
Response time, max 24h: 0 ms CRL, latest successful download: Mon Nov 05 10:27:18 GMT+01:00 2012
CRL, latest failed download: never CPR-RID, latest successful call: Mon Nov 05 10:27:23 GMT+01:00 2012
CPR-RID, latest failed call: never
DB: OK
EOS

Anchor
_Toc7255 _Toc7255

Services

Der udstilles 6 services. Disse er alle HTTP/SOAP web services. De kan findes på:
SecurityTokenService http://<sts-host>:<port>/sts/services/SecurityTokenService
NewSecurityTokenService http://<sts-host>:<port>/sts/services/NewSecurityTokenService (Bruges i forbindelse med bil-
letomveksling)
OIOSaml2Sosi http://<sts-host>:<port>/sts/services/OIOSaml2Sosi
Sosi2OIOSaml http://<sts-host>:<port>/sts/services/Sosi2OIOSaml
Saml2Idws http://<sts-host>:<port>/sts/services/Saml2Idws
Bst2Idws http://<sts-host>:<port>/sts/services/Bst2Idws
For de 3 førstnævnte vil der findes wsdl'er ved GET af selv samme url, men også som forventelig ved at postfixe ?wsdl.

Anchor
_Toc7256 _Toc7256

Certifikater

Servicen bruger certifikater til forskellige formål. Her følger en oversigt:

• SOSI føderationens certifikat også kaldet STS'ens certifikat.
• Trust certifikat til NemLogin føderationen.
• Benyttes til verifikation af billetomvekslinger (OIOSaml2Sosi og Bst2Idws)
• I testmiljøer er tilføjet 1-2 ekstra certifikater til testformål
• Tidligere har det været nødvendigt at alle certifikater i dette truststore var gyldigt. Dette ændres fra version 2.4.1 så gyldighed nu kun checkes ved en faktisk brug af certifikatet.

• Kryptering i forbindelse med omveksling (Sosi2OIOSaml).
– Her benyttes et certifikat knyttet til det audience (f.eks. sundhed.dk) der angives. Er konfiugreret i databasen.
• Keystore/Truststore til etablering af forbindelse CVR-RID og CVR-PID service.

• Benyttes til TLS forbindelse mellem STS og bagvedliggende services os Nets.
• På DNSP benyttes https direkte fra STS til Nets
• PÅ CNSP benyttes http mellem STS og Traffic Manager og https mellem traffic manager og Nets

De 2 første har udløbsdatoer. Det sidste 2 kan have. Det forventes derfor at disse certifikater fornyes inden de udløber. Procedurer herfor ligger uden for denne leverance.
Opbevaring af certifikaterne ligger ligeledes uden for leverancen, dog kan mulighederne her beskrives: Et certifikat kan ligge på filsystemet, hvor også servicen er installeret, eller det kan placeres i en Luna Boks, som kan nåes netværksmæssigt. I nogle tilfælde opbevares certifikater (public key) også i databasen.

...