Page History
...
Hele servicelandskabet i EHMI, (EHMI-SIK), er tiltænkt at køre med mutual TLS - fremover mTLS.
For at abstrahere håndteringen af dette væk fra selve kerneservicen anvendes dedikerede ingress og egress services til mTLS.
I Test1 og udvikling anvendes den gængse Testcertifikater der findes her NSP Test Identity Provider (NTIdP) - Leverancebeskrivelse under vedhæftninger.
For at lette setuppet for udviklere er lavet 2 shell scripts som klargører certifikaterne:
- https://git.nspop.dk/projects/COM/repos/sundhedsadresseringsservice/browse/setup_keycloak_trust.sh?at=develop
- https://git.nspop.dk/projects/COM/repos/sundhedsadresseringsservice/browse/setup_client_certificate.sh?at=develop
Disse scripts opsætter hhv. en Javakeystore med signeringscertifikatet fra Keycloak på Test1 (Inkl. hele certifikatkæden), samt opsætter klientcertifikater til anvendelse mod EAS og fra. EAS synspunkt mod EER.
Disse klientcertifikater er også indeholdende hele certifikatkæden.
For Keycloak trust henvises til information om access-handler NSP Access Handler - Driftvejledning#jtph.properties da konfiguration heraf er af NSP komponenten og sådan set ikke EAS.
Ingress
Udover at TLS terminerer, forwarder den hhv. klientcertifikatet og JWT token mod EAS kerneservicen.
Derved opnåes, at selve kompleksiteten med mTLS er håndteret i ingress laget, mens applikationen selv kan håndtere authentication og validere Proof of Possession af JWT token.
Dette gøres i applikationen ved at sammenholde SHA256 thumbprint af det forwarded klientcertifikat mod cnf claim i JWT token.
...
For at nginx kan validere det anvendte klientcertifikat ved mTLS skal den offentlige del af den udstedende certifikatmyndighed mountes ind i følgende mappe i nginx:
- /etc/ssl/ca.pem
...
Egress
Samme princip gør sig gældende for egress service som ingress. At abstrahere håndtering og kompleksiteten af mTLS væk fra kerneapplikationen og ud i et andet lag.
...