...

NUMBER

...

DATE

...

DESCRIPTION

...

NAME

...

0.1

...

2012-11

...

HT

...

Dokumenthistorik

Introduktion

Dette dokument indeholder en vejledning til driften af SOSI-STS

Oversigt over snitflader og adgang

Følgende er en oversigt over STS snitflader og kravene til adgang til disse.

Begreber

Disse begreber benyttes i snitfladerne nedenfor.

Java keystores.

Der benyttes et antal java keystores i løsningen. Disse er typisk placerede i folderen /pack/sts Disse beskrives nedenfor.

Konfiguration medarbejder services

...

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

...

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

...

...

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

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

...

...

...

...

...

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

...

Konfiguration af trusted, ekstern idp (omveksling fra NemLog-In til id-kort)

Denne konfiguration er i spil ved "NBO" billetomveksling, dvs fra en NemLog-In billet udstedt til en medarbejder, til et medarbejder id-kort

Konfigurationen findes i et java keystore (pt. placeret som /pack/sts/test-new-nemLogin-idp.keystore ). Dette indeholder de certifikater vi stoler på.

Der er ingen krav til hvilke alias'er disse certifikater befinder sig under.

Der er opsat trust af NemLog-in, samt evt. et eller flere yderligere certifikater til interne testformål. Det enkelte certifikat valideres i forbindelse med at det forsøges anvendt.

Fra sts 2.5.3 indgår monitorering af certifikaterne i monitorerings URL'en /sts/checkstatus.

Tilføjelse af trust til ny, ekstern idp.

1. Modtag offentlig nøgle fra den eksterne part.
2. Verificer at nøglen tilhører det rigtige miljø (test vs produktion) - og er et gyldigt FOCES certifikat
3. Indsæt nøglen under et vilkårligt alias i test-new-nemLogin-idp.keystore

4. (evt) For visse idp'er (nemlogin) stoler vi på det cpr-nummer de medsender i stedet for at validere dette. Dette er opsat i filen /pack/wildfly8/standalone/configuration/sts.services.xml (neenstående viser aktuel indstilling for produktion): 

   Code Block
   <property name="cprTrustCertificates"> <list> <value>CVR:34051178-UID:77371184</value> <!-- nemlogin prod --> </list> </property>

5. Ændringen kræver genstart af STS (eller wildfly).

Fornyelse af certifikat for ekstern idp

1. Tilføj det nye certifikat ifølge proceduren for oprettelse af ny idp - så både gammelt og nyt certifikat eksisterer samtidig.
2. Når det gamle certifikat ikke bruges mere kan dette efterfølgende fjernes ved førstkommende lejlighed.

Dynamisk konfiguration. Opsætning af gyldige nationale roller.

Ved udstedelse af id-kort, enten på baggrund af selv-signeret id-kort eller ved omveksling af NemLog-in token, er det muligt at anvende nationale roller. De gyldige roller opsættes i tabellen sts_audconf.roleDefinitions.

Nationale roller vil optræde i id-kortet som en rolle på formen urn:dk:healthcare:national-federation-role:code:40001:value:Laegesekretaer

Følgende felter er relevante

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

...

Dynamisk konfiguration. Opsætning af trust af nationale roller.

Nationale roller som beskrevet ovenfor valideres som udgangspunkt mod de roller der fremfindes i SEB. Det er dog muligt at tillade enkelte udvalgte cvr-numre (f.eks. regioner) at angive roller i id-kortet uden at få disse valideret via SEB. Dette styres via tabellen sts_audconf.trustedCvr.

Af sikkerhedsmæssige årsager anbefales funktionaliteten pt kun benyttes for 'STS'.

Borger billetomveksling

...

Dynamisk konfiguration. Billetomveksling fra Bootstraptoken eller JWT til identitytoken (Bst2Idws / JWT2Idws)

...

Omveksling fra Bootstrap token til identitytoken (også tidligere 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 formentlig også MinLog2 og Fælles stamkort).

Tilsvarende findes en omveksling fra JSON web token til identity tokens ligeledes målrettet mod borgere.

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

atributeName	Beskrivelse
lifetime

...

	Angiver gyldighed af det udstedte token, f.eks. 3600 (s). Tilstedeværelsen af denne "aktiverer" det givne audience
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, typisk signeret af NemLog-in).

...

Der kan

...

(og vil) være flere certifikater pr. audience, hvilket blot betyder at flere anvendere kan tilgå det. Disse skal blot have forskellige xxx navne.  Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen.
jwtScope	Aktiverer JWT (Json web token) support for dette audience. Omveksling kan kun foretages hvis det indgående JWT indeholder det pågældende jwtScope.

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

...

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

ID	Navn	Beskrivelse
200	AbstractStsRequestHandler. request	Alle forespørgelser, der modtages rammer dette logpunkt. Følgende attributer tilknyttes: RequestSize, ResponseSize.
210	SecurityTokenService. issueIdCard	Når et IDKort signeres, vil dette logpunkt blive ramt.
220	WsOcesCvrRidService. findRelatedCpr	Ved opslag til CVR-RID tjenesten vil dette logpunkt blive ramt. Her tilknyttes endpoint og cvr-rid værdier.
240	StsOcesCrlServiceImpl.load	Når spærrelister hentes, vil der bliver logget til dette logpunkt. Her tilknyttes endpointet (url) for CRL'en.
250	NboRequestHandler.serialize	Ved omveksling mellem OIOSaml tokens (NemLogin tokens) til SOSI idkort vil dette log punkt blive brugt.

...

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

...

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.

...

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

...

Nedenfor beskrives typiske procedurer

Konfiguration af trusted, ekstern idp (borger-billetomveksling)

Hertil benyttes samme truststore som ved omveksling fra NemLogIn til id-kort.

Samme procedurer kan anvendes.

Konfiguration af audiences til borger-billetomveksling

Disse findes i tabellen sts_audconf.audienceConfiguration.

Et nyt audience tilføjes ved at angive hvor længe et udstedt token til dette audience er gyldigt:

INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'lifetime', '300');

Der findes pt. i produktion kun et audience (https://fmk). Herudover yderligere et antal audiences i test, til interne eller eksterne testformål.

Dette audience kommer i spil, idet anvendere af borger-billetomvekslingen angiver, hvilket audience de ønsker billetten udstedt til.

Rettelsen slår igennem så snart database-rettelsen er replikeret fra backoffice til det relevante NSP-miljø

Tildeling af adgang til borger-billetomveksling for anvender system

Adgang tildeles pr audience - i enten test eller produktion.

Vi har brug for at kende SubjectSerialNumber for det certifikat (typisk FOCES) de benytter. Dette skal være et gyldigt OCES2-certifikat (test eller prod) - og BØR være et FOCES certifikat. I praksis beder vi om det offentlige certifikat og henter oplysningen ud herfra.

Herudover skal vi vide hvilket audience, samt i hvilket miljø der ønskes adgang. Adgangen godkendes af operatøren.

INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'certificate.test1', 'CVR:30808460-FID:94731315');

Navnet (i eksemplet 'certificate.test1' er ligegyldigt - det skal blot starte med 'certificate.' - resten tjener alene til at lette overskueligheden - man kan evt. indflette udløbsdatoen for nemheds skyld).

Bemærk: Kombinationen af audience og attribut skal være unik, ellers vil "duplikater" blive ignoreret.

Rettelsen slår igennem så snart database-rettelsen er replikeret fra backoffice til det relevante NSP-miljø

Certifikat fornyelser hos anvender system

Såfremt der er tale om en simpel fornyelse hos anvender systemet, hvor CVR-FID ikke ændres, skal der ikke foretages noget.

Såfremt der er tale om helt nye nøgler, indsættes den nye ved siden af den gamle. Efterfølgende kan den gamle fjernes hvis/når den ikke længere benyttes.

Konfiguration af trusted, ekstern idp (borger-omveksling fra JSON Web token til IDWS)  STS-2.5.3

Denne konfiguration er i spil ved JWT billetomveksling, som introduceres i STS 2.5.3. Dette handler om omveksler af et JSON formateret token udstedt til en borger af ekstern part (f.ek.s en OpenId connect ting).

Konfigurationen findes i et java keystore (pt. placeret som /pack/sts/test-jwt-idp-trust.jks ). Dette indeholder de certifikater vi stoler på. Status på de indeholdte certifikater kan følges på monitorerings-urlen /sts/checkstatus. Enkelte certifikater er dog frasorterede i test, idet disse udelukkende er med for at kunne teste fejlscenarier.

Der er strikse krav til hvilke alias'er disse certifikater befinder sig under.

Der er i første omgang opsat trust af et par certifikater til interne testformål. Det enkelte certifikat valideres i forbindelse med at det forsøges anvendt.

Tilføjelse af trust til ny, ekstern idp.

1. Modtag offentlig nøgle fra den eksterne part.
2. Modtag information om hvilket kid der angives i det indgående JWT (key identifier der benyttes af den eksterne part).
3. Modtag information om hvilken issuer der optræder i det indgående JWT (typisk en URL der angiver hvor den kan kontaktes - STS'en har dog ikke brug for at kunne slå den url op) 
4. Verificer at nøglen tilhører det rigtige miljø (test vs produktion) - og er et gyldigt FOCES certifikat
5. Indsæt nøglen under et alias svarende til det angivne kid i /pack/sts/test-jwt-idp-trust.jks

6. Indsæt den relevante issuer i "listen" under jwt2IdwsRequestHandler i services.xml: 

   Code Block
   <property name="issuerStrategies"> <util:map> <entry key="http://sts-tester" value-ref="keyCloak"/> <entry key="http://den-nye-issuer" value-ref="keyCloak"/> </util:map> </property>

7. Ændringen kræver genstart af STS (eller wildfly)

Fornyelse af certifikat for ekstern idp.

Samme procedure som ved oprettelse. Det nye certifikat placeres under relevante kid (=alias) ved siden af det gamle. Det vil typisk ikke være grund til at rette issuer.

Det gamle kan efterfølgende fjernes, når det ikke længere benyttes.

Konfiguration af audience til JWT billetomveksling STS-2.5.3

Dette findes ligeledes i tabellen sts_audconf.audienceconfiguration.

Det nye audience oprettes som i afsnittet ovenfor, hvis det ikke allerede findes.

Herefter tilføjes JWT-support til dette audience:

INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'jwtScope', 'clear');

Attribute_value aftales ved oprettelse, idet denne skal indgå som 'scope' i det modtagne JWT token.

Tildeling af anvender systems adgang til JWT billet omveksling

Dette fungerer helt på samme måde som ved adgang til borger-billetomveksling. Det er dog nødvendigt at anvende et audience som er "JWT-enabled", dvs. hvor jwtScope er sat.

SLA logning

Følgende tabel viser STS’ens sla logpunkter samt tilhørende navn. De enkelte logpunkter beskrives i detaljer i det følgende.

AbstractStsRequestHandler.request

Alle forespørgelser, der modtages rammer dette logpunkt.

SecurityTokenService.issueIdCard

Når et IDKort signeres, vil dette logpunkt blive ramt.

WsOcesCvrRidService.findRelatedCpr

Ved opslag til CVR-RID tjenesten vil dette logpunkt blive ramt.

WsOcesPidService.isRelated

Ved opslag til PID tjenesten vil dette logpunkt blive ramt.

ProcurationWebService.getProcurationPrivileges

Ved opslag til Fuldmagt tjenesten vil dette logpunkt blive ramt.

NboRequestHandler.serialize

Ved omveksling mellem  OIOSaml tokens (NemLogin tokens) til SOSI
idkort vil dette log punkt blive brugt.

SignatureProvider.sign

NboIdwsRequestHandler.convert