Page History

...

1. PartOf – reference til forældre SOR-noden 

Sikkerhedslogik 

Image Added

EAS servicen realisererOAuthsikkerhedsmodellen som er beskrevet i [EHMI-SIK] og som er illustreret i ovenstående figur. Aftagere af EAS servicen (eksempelvis i et klinisk fagsystem) skal kalde EAS med et accesstoken som de har fået udstedt af Sundhedsdatastyrelsens Authorization Server (Keycloak). Sikkerhedsprotokollen er baseret på 2-vejs TLS, hvor klientens accesstoken er kryptografisk bundet til klientensTLS-klientcertifikatet (se [EHMI-SIK] for detaljer). I EAS deploymentsetup’ettermineres TLS i en foranstillet netværkskomponent (NGINX), som på standard vis viderefører klientens TLS-klientcertifikat til EAS i en HTTP header. 

EAS validerer de indkommendeaccesstokensom illustreret i HAPI FHIR Security Interceptor i Figur 6. Konkret validerer EAS at: 

1. Signaturen på tokenet er valid og at tokenet er signeret af en trusted part (dvs. SDS’ kommende KeycloakAuthorization Server) 

1. Klientens TLS certifikat(som netværks/TLS-proxy’en viderefører til EAS i en HTTP header)matcher certifikatoplysningen i tokenets ’cnf’ claim.  

1. Tokenet er gyldig i tid, dvs. hverken er udløbet eller endnu ikke gyldig 

1. Tokenets level of assurance er på minimum NIST niveau 3 

1. Tokenetsscopeclaimindeholder de fornødnescopes, som er ’EAS’ og ’system/Organization.rs’ 

1. Tokenets audience (’aud’ claimet) er sat til ’EAS’ 

Der bemærkes, at NSP AccessHandlervaretager parsningenaf JTP-H access tokenet, samt står for validering 1. og 3. i ovenstående liste. 

Access- og audit-logning håndteres viaNSP AccessHandler.