The eHealth Infrastructure has two Authorization Service (AS) configurations providing authentication and authorization for client systems and internal use.
The Authorization Service configurations support the following user types of the eHealth Infrastructure:
citizen
clinical and/or administrative employee
service, support & logistics (SSL) supplier employee
system users
system administrator users
The AS configurations consists of:
One KeyCloak with
realm ehealth - for clinical and/or administrative employee login
realm nemlogin - for citizen login
One SSL KeyCloak with
realm ssl - SSL supplier employee login
System users and system administrator users exist in all the realms.
Whether authentication and authorization is federated and to which IdP does not strictly depend on the user type, but in the production environment:
citizen login is performed in realm nemlogin federated to Nemlogin
clinical and/or administrative employee login is performed in realm ehealth federated 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
SSL supplier employee login is performed in realm ssl, likely federated to SSL suppliers' IdPs
In non-production environments, these can be simulated using so-called mocked users which are authenticated (and authorized depending on variant) in the eHealth Authentication Services.
The login protocol between the client systems and the login component is the OpenID Authentication Code Flow of OpenID Connect 1.0.
After successful authentication, three tokens are issued for separate purposes:
an ID token – information for the client system about the authenticated user.
an Access Token (AT) – a token with a relatively short period of validity (few minutes), which the client systems must include in all service requests.
a Refresh Token (RT) – a token with a long validity, which can be used to renew the AT, thereby extending or resuming the session without the user having to authenticate again.
NOTE: AT and RT are tokens that may be in JWT format, but the user systems must not assume this. The format of these may change without notice, and may for example be so-called "opaque tokens", which basically are just an ID string that does not in itself carry any information.
The AT is sent as an HTTP header in all service requests in this form (where "<access token>" is replaced by a specific AT) - see https://jwt.io/introduction/ for further introduction:
Authorization: Bearer <access token>
The details on how to use these tokens will vary, depending on whether the client system is for citizens or employees, as well as specific security requirements for the called service. There will be services that do not return personal data and therefore require less protection, while other services will require both authentication, context information and more detailed authorization. The login flow is described on the Login page. The data that lays the basis for authorization and authentication is found in the final SAML Assertion that is passed to the AS.
Authentication for citizen clients
Client systems for citizens will in their (initial) login be met by NemID, which is presented via a federated login service from NemLogin. If the client system is running on a platform that supports it, it will be possible to store the RT and apply this later to resume an authenticated session, based on either pin code or biometric data. Details of this is can be read on Key Service overview, but in essence it involves selecting a PIN, registering a user / device / PIN via the Key Service, and resuming the session based on stored data and calling the Key Service.
The aim of this is to make an alternative - but simpler - "authentication" available to citizens in a secure manner.
Authentication for clinical clients
Client systems for clinical users will make a login which delegates to SEB. If there is already a session in SEB from the same browser, then a single-signon experience can be realized. Through SEB, a number of information about the user is handed over to AS, including clinical user's roles / rights. These roles and rights are embedded in the SAML Assertion using the OIO BPP 1.1 structure, model 3, described in the following section.
Authorization, SAML requirements and OIO BPP
Accessing data (one's authorization) in the eHealth Infrastructure is split into to sections; one for citizens and one for non-citizens:
Citizens are able to see almost all data to whom they are referenced (see Tokens, Roles and RBAC/ABAC). Citizens are able to create and manipulate data in the eHealth Infrastructure according to the same set of RBAC and ABAC rules.
Clinical users are able to access and manipulate data according to their affiliation to a given careteam and the role in that given careteam. The same goes for organizational data (see Tokens, Roles and RBAC/ABAC).
The rules that apply are determined by the SAML Assertion when logging in. The SAML attributes are described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2210693130/Federated+Authentication+for+Citizens#SAML-Attributes-for-Citizen-Users .
Result and impact of successful login
Clinicians
Whenever clinicians passes a successful loginflow the data from the SAML assertion is parsed and converted to the matching FHIR resources Practitioner, PractitionerRole and CareTeam which are updated in the infrastructure. This means that clinicians (FHIR Practitioners) will be present after login. This also means that clinicians that haven't logged in, won't be present as FHIR resources. Besides the creation and update of the FHIR resources, the loginflow also results in short lived session within the AS (Keycloak). The lifetime of the Keycloak session follows the lifetime of the Refresh Token.
Citizens
Citizens that logs into the infrastructure using NemID are looked up as FHIR Patient resources with the social security number found in the SAML assertion. If a match is found, the FHIR Patient resource ID will be present in the Refresh Token handed back to the client. If no match to a FHIR Patient resource is found, no FHIR Patient resource ID will be present in the Refresh Token. This means that citizens that are not part of any treatment in the infrastructure will be allowed to login, but won't have any rights to read or write any data.