Dokumenthistorik

Introduktion

Dette dokument indeholder en vejledning til driften af SOSI-STS

Begreber

I følgende dokumentation anvendes en række begreber. Den følgende liste er en liste af disse samt forklaring.

Oversigt over snitflader og adgang

Følgende er en oversigt over STS snitflader.

De enkelte snitflader er beskrevet ved at definere, hvilke anvendersystemer, brugere samt modtager de er tiltænkt.

Selve konfiguration i forhold til de enkelte snitflader er beskrevet nedenfor.

Java keystores

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

Opsætning Konfiguration af test-new-nemLogin-idp.keystore

Konfigurationen findes i et java keystore (pt. placeret som /pack/sts/test-new-nemLogin-idp.keystore ).

Dette indeholder de certifikater for troværdige tredjepart, vi stoler på.

Dette keystore anvendes af SOSI STS i forbindelse med følgende omvekslinger:

• Medarbejderomvekslingen OIOSaml2Sosi
• Borgeromvekslingen Bst2Idws

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

Konfiguration af test-jwt-idp-trust.jks **CHG: Til hvilke snitflader hører den trust? JWT2IDWS og/eller JWT2OIOSAML? **  

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 ignorerede 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. **CHG: Hvillke? Uddyb eller referer til beskrivelse **

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. Verificer at nøglen tilhører det rigtige miljø (test vs produktion) - og er et gyldigt FOCES certifikat
4. Indsæt nøglen under et alias svarende til det angivne kid i /pack/sts/test-jwt-idp-trust.jks
5. Æ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

I de følgende afsnit gennemgås konfigurationerne for de enkelte snitflader. De enkelte snitfladers opsætning beskrives og derudover beskrives en opskrift/checkliste i forhold til tilslutning af nye anvendere.

Konfiguration af DGWS

Trustmodellen for DGWS er baseret på, at anvenderen signerer det indgådende idkort ved anvendelse af et certifikat udstedt af CA rodcertifikat i den fællesoffentlige føderation.

Disse rodcertifikater vedligeholdes som en del af SEAL.JAVA biblioteket og skal derfor ikke konfigureres særskilt i STS.

Opsætning: 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');

Opsætning: 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.

Konfiguration af medarbejderomvekslinger

STS indeholder en række omvekslingssnitflader til brug for brugere af typen medarbejder.

Trustmodellen og opsætningen for de enkelte snitflader er opsummeret i nedenstående tabel og uddybet i de underliggende afsnit:

Opsætning af Sosi2OIOSaml

Den generelle konfiguration for denne service ligger i services.xml på bean iboRequestHandler og består af følgende:

Disse opsætninger er globale for alle anvendere.

Derudover vil der i forespørgsler til denne omvekslingssnitflade indgå et audience, der identificerer det tiltænkte modtagersystem.

De tilladte audience konfigureres i STS databasen i tabellen sts_audconf.iboConfig; disse er:

Opsætning: Tilføjelse af nyt modtagersystem

Der kan tilføjes nye audience ved indsættelse af en ny række i tabellen iboConfig.

USE sts_audconf;

INSERT INTO `iboConfig` 
 (audience,
  publicKey,
  recipientURL,
  includeBST,
  deliveryNotOnOrAfterOffset,
  notBeforeOffset,
  notOnOrAfterOffset,
  idCardMaxAgeMins) 
VALUES
 ('/ststest3',           'MIIGiDCCBLygAwIBAgIUGesSd7YL6KygrTfmyrVc1/w+wJYwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgMGsxLTArBgNVBAMMJERlbiBEYW5za2UgU3RhdCBPQ0VTIHVkc3RlZGVuZGUtQ0EgMTETMBEGA1UECwwKVGVzdCAtIGN0aTEYMBYGA1UECgwPRGVuIERhbnNrZSBTdGF0MQswCQYDVQQGEwJESzAeFw0yMTA0MjgxMTM4NTZaFw0yNDA0MjcxMTM4NTVaMIGeMRUwEwYDVQQDDAxWT0NFU19neWxkaWcxNzA1BgNVBAUTLlVJOkRLLU86RzpjNzBiMDIwNy0xNjJlLTRkM2QtYTdmMS1hMTlhOGUwN2Q5OWIxJjAkBgNVBAoMHVRlc3RvcmdhbmlzYXRpb24gbnIuIDk0MzU0OTY5MRcwFQYDVQRhDA5OVFJESy05NDM1NDk2OTELMAkGA1UEBhMCREswggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDMMqgvofQWw4oSUQgGydEZ/hljSZJGdbcaCJHhOawOeVF7I+ISedVayJfGptLk1iW5d92OWbINZzMW6sK6J+kcZeW+xzdwkSV42AJu7kfYw0tgkPwX+5pZbAAEYxgNbUfSEBeBTGWMn5RDIsKkryElrJ5pgmKVxvRURnG3MAieYxges8sYZyKIT3IFsAvn+cymIQ9ObvcpjOib7FMyjoxanwoDm5oRC+AxaC4nRls5gbljrDtu5CuqkOTWajnyFyvMGbDJYagT6IwLRAGFRuGGFdzK9JOZi8X5Zk8e98Fg2O2/DzvIv15bmocpCsSu8gp2fjryYBjdK2eEO2E7uyohd2xBMFwaTop18PVQz1wXA9i3o3VGbcga2+/aIjjgBNnstDzujthgDHu+ib/WlwVAkYU5jVrQQJF3GsVxEQ0oWcNYMQvkF+K7U4YJiiWzXHr2wzC/36xQmZR6i3U626f86J0jHZGm6K4Xo6+5jXBblIhy/XYFhDXqHUooJSxmRxUCAwEAAaOCAYYwggGCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUfyif2XGZQuJ159c1di5NCCVtdl4wewYIKwYBBQUHAQEEbzBtMEMGCCsGAQUFBzAChjdodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY2FjZXJ0L2lzc3VpbmcuY2VyMCYGCCsGAQUFBzABhhpodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2NzcDAhBgNVHSAEGjAYMAgGBgQAj3oBATAMBgoqgVCBKQEBAQMHMDsGCCsGAQUFBwEDBC8wLTArBggrBgEFBQcLAjAfBgcEAIvsSQECMBSGEmh0dHBzOi8vdWlkLmdvdi5kazBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY3JsL2lzc3VpbmcuY3JsMB0GA1UdDgQWBBTMXLy9NQtbqHed6JtCTmjx4/aUZTAOBgNVHQ8BAf8EBAMCBeAwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgA4IBgQA9MCrGkd1WfucACqjxSCnpoBqYRHTXrKYjSIarHnjaUMEXMZOixgIi6rk9jdiAX2L+6aY/lee++LejbfR2Immry+w50EpgIGI7jsJ/7ggSN5ySpu6lZpZcZ4KfB2Lx1CYH8AVWgQXDtOrvIGKQxSWY0qwey4M5weBhUGPDrEpu/7k3mMqIIZF1x5CtlrWJZ+bVm9Ohh+f8Yf7scWb14iciA0H85PRAXOvWoN13od2a35mqZqBMaW+4ExvmXailbEmuS1Smr1mcKNVP4ABeW/Oh621VEwChB/OnRpsp5+TjDxenoFQ9vPJm/M/zAke1G3U7Yje0qyi7ke8JxTtMqH0hP8O43WGlloL1NfvXXzigZTGrmVxcPB7HSHPzTINXfF/sqXmBfaHuUuIJqScwDNqwKoJQQLKeE8hhLFYmRdZ+HvgeIzv6aAbfp0h5vpwwpfNjhENuYGSjkI8nzoFmcmQgjXFt1o2xqlVSCU4rZLtqpMKDCnWFPFvblhmkHx7vcVE=',
  '/ststest/login', 
  true, 
  0, 
  0, 
  3600000, 
  null);

Tilføjelse af ny anvender

Ovenstående tabel skal kun opdateres hvis servicen skal benyttes for et audience, der ikke allerede er konfigureret. I så fald, tilføjes en ny række i tabellen for det nye audience.

OIOSaml2Sosi

Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration:

Trust til eksterne idp'er er sat op i test-new-nemLogin-idp.keystore (trustedVault i konfigurationen). Se afsnittet om Java keystores.

Tilføjelse af ny trusted IdP

Hvis der skal tilføjes trust til en ny idp, skal det opdateres i test-new-nemLogin-idp.keystore, som beskrevet i afsnittet om Java keystores.

Evt. kan property cprTrustCertificates opdateres.

Tilføjelse af ny anvender

BST2SOSI

Den generelle konfiguration for denne service ligger i services.xml på bean BST2SOSIRequestHandler:

Omvekslingen kræver også konfiguration for hver issuer i databasen i tabellen sts_audconf.trustedIdpConfiguration:

Gyldige attributter i tabellen er:

Tilføjelse af ny anvender

Er der tale om en ny issuer, skal der tilføjes rækker til ovenfor nævnte tabel for hver attribut. 

Er issuer allerede i tabellen, skal der oprettes:

• Evt. en ny encryptionKey.xxx attribut med krypteringsnøglen (hvis den ikke allerede er til stede), og tilsvarende encryptionPublicKey.xxx
• En ny certificate.xxx attribut med ssn for anvendercertifikatet
• En ny signingKey.xxx attribut med nøglen til certifikatet der bruges til signering af bootstraptokenet (hvis det ikke allerede er til stede).

Nationale roller

Konfiguration af borgeromvekslinger

Bst2Idws

Omveksling fra Bootstrap token til identitytoken benyttes til at veksle et Bootstraptoken udstedet af NemLog-in på vegne af en borger, til et identitytoken, der kan benyttes til borgersnitflader (IDWS snitflader) udbudt af f.eks. FMK, DDV, MinLog2, MinSpærring og Dokumentdelingsservicen.

Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration, ligesom for OIOSaml2Sosi omvekslingen. Til denne omveksling benyttes dog kun de to properties fuzzyTime og allowedDriftInSeconds.

Database tabellen sts_audconf.trustedIdpCitizenConfiguration benyttes til konfiguration for issuers af de indgående bootstraptokens. Tabellen er på samme form som sts_audconf.trustedIdpConfiguration (se BST2SOSI).
Gyldige attributter i tabellen er:

Herudover benyttes tabellen sts_audconf.audienceConfiguration til konfiguration pr. audience.

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

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

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

Tilføjelse af ny anvender

Er den angivne issuer endnu ikke konfigureret, skal trustedIdpCitizenConfiguration tabellen opdateres med attributter for denne.

Er issuer allerede i trustedIdpCitizenConfiguration tabellen skal der oprettes:

• Evt. en ny encryptionKey.xxx attribut med krypteringsnøglen (hvis den ikke allerede er til stede), og tilsvarende encryptionPublicKey.xxx
• En ny signingKey.xxx attribut med nøglen til certifikatet der bruges til signering af bootstraptokenet (hvis den ikke allerede er til stede).

Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.

Er audience allerede i audienceConfiguration tabellen, skal der oprettes en ny certificate.xxx attribut med ssn for anvendercertifikatet.

JWT2Idws

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

Den generelle konfiguration for denne service ligger i services.xml på bean jwt2IdwsRequestHandler:

Trust til eksterne idp'er er sat op i test-jwt-idp-trust.jks (property trustStoreFile). Se afsnittet om Java keystores.

Ligesom for Bst2Idws kræves konfiguration i database tabellen sts_audconf.audienceConfiguration. Dog med en ekstra attribut.

Tilføjelse af ny anvender

Er den angivne issuer endnu ikke konfigureret, skal test-jwt-idp-trust.jks opdateres, som beskrevet i afsnittet om Java keystores. Derudover skal property issuerStrategies opdateres i services.xml med den nye issuer.

Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.

Er audience allerede i audienceConfiguration tabellen, skal der oprettes en ny certificate.xxx attribut med ssn for anvendercertifikatet. Anvender skal kende det eksisterende jwtScope.

JWT2OIOSaml

Den generelle konfiguration for denne service ligger i services.xml på bean sboRequestHandler:

Ligesom for JWT2Idws, er trust til eksterne idp'er sat op i test-jwt-idp-trust.jks (property trustStoreFile). Se afsnittet om Java keystores.

Audience konfiguration ligger i databasen i tabellen sts_audconf.audienceConfiguration ligesom Bst2Idws og JWT2Idws. Dog med lidt flere attributter:

Tilføjelse af ny anvender

Er den angivne issuer endnu ikke konfigureret, skal test-jwt-idp-trust.jks opdateres, som beskrevet i afsnittet om Java keystores. Derudover skal property issuerStrategies opdateres i services.xml med den nye issuer.

Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.

Er audience allerede i audienceConfiguration tabellen, skal der oprettes en ny certificate.xxx attribut med ssn for anvendercertifikatet. Anvender skal kende det eksisterende jwtScope.

Certifikat fornyelser hos anvender system

Såfremt der er tale om en simpel fornyelse hos anvender systemet, hvor SubjectSerialNumber 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.

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

Monitoring

Sts kan overvåges ved at tilgå monitoreringsendpoint: /sts/checkstatus

Nedenstående er et eksempel på output:

Version: 2.8.6-SNAPSHOT
Local time: Tue Jan 04 13:50:45 CET 2022
Started: Tue Jan 04 08:56:47 CET 2022
Last transaction: Tue Jan 04 08:58:23 CET 2022
Last issued: Tue Jan 04 08:58:23 CET 2022
Sts certificate, valid from: Tue Apr 30 11:07:17 CEST 2019
Sts certificate, valid until: Sat Apr 30 11:06:38 CEST 2022
Sts certificate valid: OK
Requests, 24h: 604
Requests, total: 604
Failed requests, 24h: 58
Failed requests, total: 58
Response time, avg 24h: 33 ms
Response time, max 24h: 888 ms
CRL, latest successful download: Tue Jan 04 08:55:51 CET 2022
CRL, latest failed download: never
CPR-RID, latest successful call: Tue Jan 04 08:58:00 CET 2022
CPR-RID, latest failed call: never
CPR-PID, latest successful call: Tue Jan 04 08:58:12 CET 2022
CPR-PID, latest failed call: never
Procuration, latest successful call: Tue Jan 04 08:57:53 CET 2022
Procuration, latest failed call: never
UUID2CPR, latest successful call: Mon May 16 13:25:58 CEST 2022
UUID2CPR, latest failed call: never STS-DB: OK
CRA-DB: OK
Trusted certificate NBOTrustStore/foces3_2024 -> UI:DK-O:G:23550132-5e1f-4e43-a5f9-048acf49e0b8: OK (Expires: 27-04-2024 14:25:47)
Trusted certificate NBOTrustStore/nemlogin_test -> CVR:34051178-FID:56940413: Expired (Expires: 20-04-2020 10:18:26)
Trusted certificate NBOTrustStore/test_voces3_2024 -> UI:DK-O:G:c70b0207-162e-4d3d-a7f1-a19a8e07d99b: OK (Expires: 27-04-2024 13:38:55)
Trusted certificate NBOTrustStore/lakeside_test -> CVR:25450442-FID:bootstrap: Expired (Expires: 24-02-2020 14:55:12)
Trusted certificate NBOTrustStore/sundhed_dk_test -> CVR:31908574-FID:96424869: Expired (Expires: 08-05-2020 08:51:49)
Trusted certificate NBOTrustStore/ssi_foces_2021 -> CVR:46837428-FID:92421325: OK (Expires: 16-08-2024 08:49:11)
Trusted certificate NBOTrustStore/ssi_voces_2021 -> CVR:46837428-UID:27910135: OK (Expires: 16-08-2024 08:47:23)
Trusted certificate JWTTrustStore/revoked -> CVR:30808460-FID:45327473: Ignored (Expires: 16-12-2022 15:33:47)
Trusted certificate JWTTrustStore/mk934ncocn5gwbyvvvegdce6d0ansvlz8dpljbt-0ty -> CVR:33257872-FID:68451797: Expired (Expires: 30-07-2021 07:42:33)
Trusted certificate JWTTrustStore/ssi_foces_2024 -> CVR:46837428-FID:92421325: OK (Expires: 16-08-2024 08:49:11)
Trusted certificate JWTTrustStore/test_foces3_2024 -> UI:DK-O:G:23550132-5e1f-4e43-a5f9-048acf49e0b8: OK (Expires: 27-04-2024 14:25:47)
Trusted certificate JWTTrustStore/expired -> CVR:30808460-FID:50912949: Ignored (Expires: 25-03-2014 21:52:13)
Trusted certificate JWTTrustStore/ssi_foces -> CVR:46837428-FID:92421325: Expired (Expires: 03-09-2018 16:21:07)
Trusted certificate JWTTrustStore/revoked_foces3_2024 -> UI:DK-O:G:730038f6-1662-4a4f-a6e0-1a550347fa2f: Revoked (Expires: 27-04-2024 14:42:14)
EOS

Som en del af outputtet leveres information om de trustede certifikater, der i øjeblikket er konfigureret i STS. Formatet af disse linjer følger følgende skabelon Truststore/alias - > SubjectSerialNumber: Status (Expires: Not-After)

Certifikater, der er på ignorelisten vil optræde i output, men deres faktiske status vil ikke påvirke den samlede status rapporteret i endpointet.

Genstart

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