Authentication and Authorization
This page outlines the authentication and authorisation mechanisms used across the platform. It details how different user types—such as citizens, clinicians, and system users—are authenticated via federated login systems and how access is controlled using tokens and contextual information.
Content
Subpages
- Token Based Security — This is a description of the token-based security the eHealth infrastructure uses to authenticate the identity of users and control access to resources.
- Federated Authentication for Citizens — This page describes the federated login for citizens using NemLogin as IdP, and the required SAML attributes for citizen users.
- Federated Authentication and Authorization for Municipal and Regional Users — This page describes the login flow for clinal users and the SAML attributes required in the SAML Tokens for municipal and regional users.
- Federated Authentication and Authorization for Municipal Users — Description of federated authentication and authorization for Municipal Users using SEB and KOMBIT ConcextHandler.
- Federated Authentication and Authorization for Regional Users — Federated authentication and authorization flow for Regional Users using SEB and regional IdP.
- Basic Privilege Profile — The eHealth infrastructure uses OIOSAML Basic Privilege Profile 1_2 (digst.dk) https://digst.dk/media/20999/oiosaml-basic-privilege-profile-1_2.pdf to express user privileges as attributes in SAML Assertions.
- OIO BPP Tool — OIO BPP Tool is an online tool that can be used to create, edit and encode OIO BPP XML documents.
- Authentication and Authorization for Local Users
- Simulated Federation of Authentication and Authorization
- Mocking Context for patient users — Description of how to mock patient users.
- Mocking Context — Description of how to mock context.
- OIO BPP Role to eHealth Privilege mapping — OIO BPP role groups several privileges in the eHealth infrastructure. In Token Based Security there is a description of the OIO BPP role names in the eHealth Infrastructure. This page lists for each role the set of privileges for that role.
- National Roles
- Assisted Login for Citizens
Authorisation Service Configurations
The Authorisation Service configurations support the following user types of the eHealth Infrastructure:
citizen
clinical and administrative employee
service, support & logistics (SSL) supplier employee
system users
system administrator users
The AS configurations consist of one KeyCloak with
Realm ehealth - for clinical and administrative employee login
realm nemlogin - for citizen login
System users and system administrator users exist in all realms.
Authentication and Authorisation Flow
The login protocol between the client systems and the login component is the OpenID Authentication Code Flow of OpenID Connect 1.0.
Further details on the client’s initiation are described in Client Application use of eHealth Infrastructure authentification server (AS). As a reaction, the Authorisation Service initiates a federation of authentication and possibly authorisation depending on the realm:
The realm nemlogin is federated to Nemlogin
realm eHealth is 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
In non-production environments, a login without this federation taking place can be simulated through use of the so-called mocked users. Mocked users are authenticated (and authorised depending on the variant) in the eHealth Authentication Services.
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 (a few minutes), which the client systems must include in all service requests.
a Refresh Token (RT) – a token with long validity, which can be used to renew the AT, thereby extending or resuming the session without the user having to authenticate again.
The set of services and service operations that the client is authorised to use privileges is conveyed through the Access Token. The set depends on user type and/or federated authentication. The eHealth services perform access control based on the Access Token, often constrained by additional contexts that must be set in the Access Token.
Authorisation Based on User Type and Contexts set in the Access Token
The eHealth infrastructure defines the following contexts:
Organization Context
Careteam Context
Patient Context
Episode of Care Context
The following is an informative overview of user types that must present in what contexts. The normative mapping is described in Access Control in eHealth Services.
Citizen User Type and Contexts
A citizen user type is authorised to see almost all data about the citizen.
This user type will have the Patient Context set.
In general, modifying data requires the Episode of Care Context to be set.
Citizens who log 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 who are not part of any treatment in the infrastructure will be allowed to log in, but won't have any rights to read or write any data.
Clinical and/or Administrative Employee User Type and Contexts
Whenever clinicians pass a successful login flow, 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 who haven't logged in won't be present as FHIR resources. Besides the creation and update of the FHIR resources, the login flow also results in a short-lived session within the AS (Keycloak). The lifetime of the Keycloak session follows the lifetime of the Refresh Token.