| Excerpt |
|---|
This is a description of the token-based security the eHealth infrastructure uses to authenticate the identity of users and control access to resources. |
| Table of Contents |
|---|
Token Based Security
Once the user is logged in, the eHealth Authentification Server (AS) hands out a set of tokens (see Authentication and authorization for details on the tokens) are handed out by the AS (based on the OIO SAML AuthResponse). These tokens serve as 'tickets' and are verified and asserted every time the user interacts with the eHealth Infrastructure. If deemed .
The tokens are based on the OIO SAML AuthResponse. See Authentication and Authorization for details on the tokens.
If the eHealth Infrastructure deems the tokens invalid or expired by the eHealth Infrastructure, no further interaction happens and the user is denied from accessing or manipulating data. As the tokens from the login initially are a very broad spectrum, little or no data is accessible. This entirely depends on the information given in the OIO SAML AuthResponse. If the user e.g. happens to be part of multiple careteams, the AS is unable to supply proper default values as the choice is not unambiguously. This is due to the fact that because the access to data under each careteam may differ from careteam to careteam. In order to actually To gain access to eg. clinical or organizational data, the user needs to actively choose in which context the user wants to interact. Based on the choice of context, the eHealth Infrastructure can forge a new set of tokens (based on the initial handed-out tokens + the chosen context - see Switching Context for details) which then provides access under the given chosen context.
...
Each time one or more of these context items are provided in the step where the user chooses a given context, a consistency check is made in the eHealth Infrastructure order to check that the chosen set of context items actually fits together. All in all, without going into details it can be stated that the security model does both RBAC and ABAC security checks.
...
When a user is logged into the eHealth Infrastructure a set of tokens are issued to the user. The This section explains the Access token is explained in further detail in this section.
The Access token is a JWT with a set of fields that explain what a user is allowed to do in combination with the applied context. The fields of the JWT are the following:
JWT | Meaning | Example |
|---|---|---|
preferred_username | value of SAML attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name | C=DK,O=TRIFORK A/S // CVR:20921897,CN=Lasse Læge-Dam,Serial=CVR:20921897-RID:93134986 |
name | value of SAML attribute urn:oid:2.5.4.3 | Lasse Læge-Dam |
jti | 2ef5b6b1-a667-40f5-b468-f475cdcef5ec | |
exp | 1556110351 | |
nbf | 0 | |
iat | 1556110051 | |
iss | ||
aud | EHealth | |
sub | 88c4feb3-f87a-43c6-9141-fc03a3944ad6 | |
typ | Bearer | |
azp | EmployeeClient | |
acr | 1 | |
auth_time | 0 | |
scope | Scope is either ehealth or nemlogin | profile openid ehealth |
realm_access | List of process privileges – eg. what is the user allowed to do in combination with the context. | "realm_access": { "roles": [ "Patient.read", "Patient.write" ] } |
context | List of items that are set in context. context in combination with items in realm_access governs the access to all resources in the ehealth infrastructure. | "context": { "organization_id" : "https://fut.com/fhir/Organization/1", "care_team_id": https://fut.com/fhir/CareTeam/4, "episode_of_care_id": https://fut.com/fhir/EpisodeOfCare/10, "patient_id": "https://fut.com/fhir/Patient/8" } |
user_id | Id of the user. Can be either a FHIR patient Id, FHIR practitioner Id or a KeyCloak Id | "user_id": " e03ccef7-b0b1-4f68-8e16-6fc2f865a922" |
user_type | Can be either SYSTEM, PATIENT, PRACTITIONER or SSL | "user_type": "PATIENT" |
What operations that the user is allowed to do is stated in the "realm_access" attribute. In the example above the user is allowed to issue a "Patient.read" and a "Patient.write". This means that the user can get and edit patient records. This part of the security model is the RBAC part, as the claims here are entirely based upon on what role the user has. Each resource type (see https://docs.ehealth.sundhed.dk/latest/igfhir/profiles.html) has certain restrictions to what context must be issued, in order to allow data retrieval or data manipulation. This is stated in the Access rights section below (For instance, in order to either read/search or write to a patient, the patient must be in context). Furthermore, the context attribute shows what data is in context. The set of items that can be set into context are Organization, Patient, CareTeam, and EpisodeOfCare (see Switching Context). As such, the eHealth Infrastructure governs the access to data using both RBAC (stated roles from login) and ABAC (asserting data attributes on the actual content).
...
The current list of privilege roles defined is given in the table below.
OIO BPP Role to eHealth Privilege mapping lists all the privileges for each role.
Role name in OIO BPP | Domain | Danish name | Description (non-normative) | Privileges (Danish) | OIO Data constraints (Exttest) | OIO Data constraints (Prod) | |
|---|---|---|---|---|---|---|---|
| 1 |
| Administrative | Care Team administrator | Role capable of creating and maintaining careteams |
|
| |
| 2 |
| Clinical | Borgeropretter | Role capable of initiating episode of care and setting up careplans for Citizen |
|
| |
| 3 |
| Administrative | Pakke- og forløbsbygger | Role capable of creating and maintaining plan definitions |
|
| |
| 4 |
| Support, Service & Logistics | Klinisk supporter | Role capable of searching and updating communications related to support and incidents |
|
| |
| 5 |
| Clinical | Klinisk se adgang | Role capable of viewing a citizen's demographic data, careplans and measurements. |
|
| |
| 6 |
| Support, Service & Logistics | Support samarbejdspartner | Role capable of dispatching incidents and tracking status. |
|
| |
| 7 |
| Support, Service & Logistics | Fejlmelder | Role capable of creating and maintaining communications related to support and incidents. |
|
| |
| 8 |
| Clinical | Monitoreringstilretter | Role capable of maintaining careplans, setting up measurement regimes and reference ranges, suspending and reactivating careplans, handling communication with Citizen. |
|
| |
| 9 |
| Clinical | Monitoreringsmedhjælper | Role capable of handling measurements and communication with Citizen. |
|
| |
| 10 |
| Support, Service & Logistics (secondary: Clinical) | Bestiller af udstyr | Role capable of accessing carePlans, placing orders for devices and services, maintaining orders |
|
| |
| 11 |
| Administrative | Sundhedsfaglig spørgeskemaeditor | Role capable of creating and maintaining questionnaires |
|
| |
| 12 |
| Administrative | Nøgletalsmedarbejder | Role capable of generating reports for statistics and administration |
|
| |
| 13 |
| Support, Service & Logistics | Service og logistik samarbejdspartner | Role capable of processing orders for devices and services |
|
| |
| 14 |
| Support, Service & Logistics | Katalogopmærker | Role capable of accessing SSL catalogues and maintaining annotations about devices |
|
| |
| 15 |
| Support, Service & Logistics | Katalogansvarlig | Role capable of creating and maintaining SSL catalogues |
|
| |
| 16 |
| Support, Service & Logistics | Aftaleansvarlig | Role capable of creating and maintaining SSL contracts and involved parties |
|
| |
| 17 |
| Administrative | Terminologiadministrator | Role capable of creating and maintaining terminology |
|
|
Mapping Privilege Roles to Roles
Each privilege role maps to a set of roles stated in the JWT attribute "realm_access". The table below illustrates this by example. These roles are the RBAC part of the security model.
Role name in OIO BPP |
|---|
Unfolded to | |
|---|---|
| Patient.read, Observation.read, CareTeam.read, Organization.read, … |
| PlanDefinition.read, PlanDefinition.write, ActivityDefinition.read, ActivityDefinition.write, … |
The current mapping in effect can be retrieved from KeyCloak as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/270991361/Switching+Context#Mapping-from-Role-to-Privileges.
Access
...
Control
See Access Control in eHealth Services for details on the access control in eHealth Services.