Summary

In summary, the eHealth ecosystem has security based on:

• Authentication and authorization by an Authorisation Service (AS) Keycloak instances issuing JSON web tokens (JWT) for the Administrative Domain and Clinical Domain. This is split into two realms:

  • realm ehealth - for employee (clinical) login

  • realm nemlogin - for citizen login

• Federated Authentication (and sometimes Federated Authorisation)

  • 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 IdPs for regional users

    • Authorisation based on externally known system roles, organisational context, and possibly care team context

• Token based security

• Client use based on OpenID Connect 1.0 Authentication Code Flow with PKCE

  • Client types, login, and requirements

  • Selecting and switching contexts in JWT

  • Token exchange

• Access Control is enforced in eHealth services

  • Based on Role-Based Access Control (RBAC) on the 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 Authorisation Server (AS) governs access to eHealth Infrastructure data and services. The AS is responsible for handing out properly signed tokens 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 a range of services (among these are services on the NSP).

For the clinical and citizen realms, the AS is federated with two services that provide the identity of the users:

• NemLogin

• SEB

NemLogin

The NemLogin service is intended to be used by citizens to gain access to data in the eHealth Infrastructure. NemLogin uses NemID to provide the services needed as an IdP endpoint.

SEB (danish: Sundhedsvæsenets Elektroniske Brugerstyring)

SEB is a common platform for user administration of the solutions provided by the National Health Data Authority on both the Internet and the secure Sundhedsdatanettet. SEB is based on a platform that takes into account OIO standards in this area. SEB provides a federation with regional instances and municipal instances. How this federation is constructed is beyond the scope of the eHealth Infrastructure.

To the eHealth Infrastructure, SEB primarily serves two purposes:

• Provide a homogenous interface from its federated IdPs towards the eHealth Infrastructure

• Doing the actual federation between the regional instances and the municipal instances

Open

eHealth Infrastructure Federation (simplified)

Login and security flow

When looking at the eHealth Infrastructure from the outside, the login flow looks like a regular OIDC login flow, whereas the internal trust and federation are based on SAML. The AS used in the eHealth Infrastructure seamlessly bridges these security protocols, thereby making it easier for clients to access the eHealth Infrastructure to gain the needed federated access to the actual services. As depicted in the diagram, the "User application" initiates the login flow with the infrastructure but is redirected to federated services. The flow is as follows:

• The AS supports login using OpenID Connect "code flow" while NemLogin and SEB support OIO SAML.

• The AS bridges these security flows by sending back a redirection if no token is provided when interacting with the eHealth Infrastructure (NemLogin and SEB each have their own security realm in the AS, meaning that the redirection logic is unambiguous).

• The sequence of redirects (and SAML AuthRequests/Responses) that takes place between the app and its federated endpoint, before the AS is finally invoked with a SAML AuthResponse, is not of concern to the eHealth Infrastructure (but in the case of SEB, it probably involves redirects from SEB back to the user's own IdP and back again). See Login for details.

• While NemLogin provides details on the identity of the citizen, such as name and civil registration number (the authentication part), SEB also provides details on the user in regards to what roles apply (both authentication and authorisation).

• It is beyond the scope of the eHealth Infrastructure to describe how and when these roles are applied in the federated setup. It is expected that the authorisation part is governed by the IdP itself.

• As no roles are issued from NemLogin, it means that citizens, by default, can only read data marked as theirs/involving them, with a few exceptions. Users (clinical users), however, are provided with roles (from SEB or the IdP) scoped within an organisation or a careteam (a careteam, in short, is a set of clinical users that provides services to a citizen. Users in careteams are not restricted to originating from the same region/municipality). Users can be in multiple careteams at the same time.

The OIO SAML part of the flow and the requirements for SAML assertions can be found on the pages Login and Authentication and authorization. These pages should be inspected by administrators of the municipality IdP's and regional IdP's.

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 describe how the tokens are formed and when they should be exchanged for a more narrow and specific token.

Sub pages

Detailed parts of the security documentation can be found on the following pages: