| Excerpt |
|---|
Overall description of the eHealth security mechanism for authentication and authorization |
In summary, the eHealth eco system has security based on:
Two Authorization Server (AS) Keycloak instances issuing JSON web tokens (JWT)
One for the Administrative Domain and Clinical Domain, split in:
realm ehealth - for employee (clinical) login
realm nemlogin - for citizen login
One for the Service, Support & Logistics (SSL) Domain with
realm ssl - for SSL supplier employee login
OpenID Connect 1.0 Authentication Code Flow with PKCE
Client types, login, and requirements
Selecting and switching contexts in JWT
Token exchange
Federated Authentication (and sometimes Federated Authorization)
For realm nemlogin: Federated using SAML to Nemlogin
For realm ehealth: Federated using OIOSAML to SEB (in Danish: Sundhedsvæsenets Elektroniske Brugerstyring shortened SEB) which is a common platform for user administration of the solutions provided by the National Health Data Authority
Federated to Municipal IdPs through the IdP proxy KOMBIT Context Handler for municipal users
Federated to Regional IdP for regional users
Authorization based on externally known system roles, organisational context and possibly care team context
Access Control enforced in eHealth services
Based on Role Based Access Control (RBAC) on privilege level
Mapping of externally known system roles to privileges
Based on Attribute Based Access Control (ABAC)
Using special contexts selected and contained in JWT
Access to eHealth Infrastructure data and services are governed by the eHealth Infrastructure Authorization Server (AS). The AS is responsible for handing out tokens that are properly signed with the correct level of detail embedded. Without a token, no access is provided. The eHealth Infrastructure is by intent and design not part of any other existing infrastructure such as the NSP. Instead, it integrates to a range of services (among these are services on the NSP).
...