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

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 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/services.xml (neenstående viser aktuel indstilling for produktion): 

   <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 er ikke nødvendigt at genstarte før ændringer træder i kraft - der kan dog være op til 10 minutters forsinkelse.

Eksempel-SQL:

use sts_audconf;
insert into roleDefinitions (source, externalName, code, value) values ('NationalFederation', 'nspPlejeAssR3', '41003', 'PlejeAssR3');

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

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

Nedenfor beskrives typiske procedurer

Dynamisk konfiguration. Billetomveksling fra JWT til OIOSaml (JWT2OIOSaml)

Omveksling fra JSON web token til OIOSAML token er målrettet borgere. Det kræver en konfiguration i databasen i tabellen sts_audconf.audienceConfiguration.

Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value. For et givet audience (f.eks. http://forloebsplaner.dk) kan der være følgende indgange

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 (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: 

   <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

Genstart

Servicen kan genstartes ved at genstarte den docker container, som servicen den kører i.