...
In summary, the eHealth eco system has security based on:
Two Authorization Server Authentication and authorization by two Authorization Service (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
...
The eHealth Infrastructure security model relevant for User application developers can be found on the pages Tokens, Roles and RBAC/ABAC, Switching Context and Key Service overview. These pages describes how the tokens are formed and when they should be exchanged for a more narrow and specific token.
...