Page Comparison

A key component of the eHealth Infrastructure security model is to switch context. Switching context means that the user asks the Authentication/Authorization Server (AS) to issue a new set of tokens where the content of the Access token contains a new context. The parameters for requesting a new context are any of the following:

...

In order to set a context, the requester needs to obtain what is available to be set in context.

Available Contexts

The available contexts for any a given user can be obtained by querying (the AS using an HTTP GET with the current Access token ) the AS at the path /auth/realms/{realm name}/resource/ehealth-connect/contexts on the AS.

The result is an expanded tree that lists available careteams and organizations, e.g. for a clinical user:

...

Contexts

GET https://saml.exttest.ehealth.sundhed.dk/auth/realms/ehealth/resource/ehealth-connect/contexts
Response:
{
  "care_teams": [ 
    {
      "id": "https://fut.com/fhir/CareTeam/4",
      "name": "Careteam Nord"
      "affiliation": {
        "id": "https://fut.com/fhir/Organization/38",
        "name": "Region Midtjylland, Aarhus Universitetshospital, Lungesygdomme"
      },
      "roles": [
        "urn:dk:sundhed:ehealth:role:clinical_viewer"
      ]
    },
    {
      "id": "https://fut.com/fhir/CareTeam/6",
      "name": "Careteam Syd"
      "affiliation": {
        "id": "https://fut.com/fhir/Organization/1",
        "name": "Aarhus Kommune, Center Syd"
      },
      "roles": [
        "urn:dk:sundhed:ehealth:role:clinical_viewer",
        "urn:dk:sundhed:ehealth:role:citizen_enroller"
      ]
    } 
  ],
  "organizations": [
    {
      "id": "https://fut.com/fhir/Organization/1",
      "name": "Aarhus Kommune, Center Syd",
      "roles": [
        "urn:dk:sundhed:ehealth:role:questionnaire_editor"
      ]
    },
    {
      "id": "https://fut.com/fhir/Organization/2",
      "name": "Æbeltoft Kommune, Afdeling Vest",
      "roles": [
        "urn:dk:sundhed:ehealth:role:terminology_administrator",
        "urn:dk:sundhed:ehealth:role:questionnaire_editor"
      ]
    }
  ]
}

Mapping from Role to Privileges

...

As of Keycloak version 1.8.40, a list of the top-level roles for each available context is given in the “roles element“. Each top-level role is expanded to a set of privileges. This mapping can be obtained by querying (HTTP GET with the current Access token) the AS at the path /auth/realms/{realm name}/resource/ehealth-connect/groups. The result is a map of top-level roles to privileges. The example request and response shown below illustrate the concept and are not intended to be normative, complete or kept up-to-date.

Groups

GET https://saml.exttest.ehealth.sundhed.dk/auth/realms/ehealth/resource/ehealth-connect/groups
{
    "urn:dk:sundhed:ehealth:role:questionnaire_editor": [
        "Questionnaire.update",
        "DocumentReference.write",
        "DocumentReference.*",
        "Questionnaire.patch",
        "DocumentReference.read",
        "DocumentReference.update",
        "DocumentReference.search",
        "Organization.read",
        ...
    ],
    "urn:dk:sundhed:ehealth:role:clinical_viewer": [
        "DeviceUseStatement.search",
        "Condition.search",
        "DeviceMetric.read",
        "DocumentReference.read",
        "DocumentReference.search",
        "RestrictionCategory$none",
        "$search-measurements",
        ...
    ],
    "urn:dk:sundhed:ehealth:role:terminology_administrator": [
        "CodeSystem.write",
        "Terminology Administrator",
        "ConceptMap.write",
        "ValueSet.write",
        "NamingSystem.write"
    ],
    "urn:dk:sundhed:ehealth:role:citizen_enroller": [
        "Condition.search",
        "CarePlan$update-care-teams",
        "DocumentReference.read",
        "Consent.create",
        "DocumentReference.search",
        "CareTeam.read",
        "Consent.update",
        "ServiceRequest.delete",
        "Consent.patch",
        "EpisodeOfCare.write",
        "Questionnaire.search",
        ...
    ],
    ...
}

Setting the Context

In order to set the context, the AS can be requested with a valid refresh token using an HTTP POST (x-www-form-urlencoded) against auth/realms/{realm name}/protocol/openid-connect/token with the required and optional parameters listed below. The result is a valid Access Token Response[1] where the access token in the response will have the requested context set.

...

Note: The original JWT used to obtain a new JWT with the context set is still valid for other operations.

Example: Access token with context

...

{
    "jti": "2ef5b6b1-a667-40f5-b468-f475cdcef5ec",
    "exp": 1556110351,
    "nbf": 0,
    "iat": 1556110051,
    "iss": "https://inttest.ehealth.sundhed.dk/auth/realms/inttest",
    "aud": "EHealth",
    "sub": "88c4feb3-f87a-43c6-9141-fc03a3944ad6",
    "typ": "Bearer",
    "name": "Lasse Læge-Dam",
    "azp": "EmployeeClient",
    "auth_time": 0,
    "session_state": "e03ccef7-b0b1-4f68-8e16-6fc2f865a967",
    "acr": "1",
    "user_id": "e03ccef7-b0b1-4f68-8e16-6fc2f865a922",
    "user_type": "SYSTEM",
    "realm_access": {
        "roles": [
            "offline_access",
            "uma_authorization",
            "Patient.read",
            "Patient.write"
        ]
    },
    "context": {
        "organization_id": "https://fut.com/fhir/Organization/38",
        "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"
    },
    "scope": "profile openid ehealth",
    "preferred_username": "C=DK,O=TRIFORK A/S // CVR:20921897,CN=Lasse Læge-Dam,Serial=CVR:20921897-RID:93134986"
}

Sequence

...

Flow

The diagram below illustrates the interacting parts when logging in and requesting a context:

...