Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt

Description of how client applications can switch context and Authentication/Authorization Server (AS) to issue a new set of tokens where the content of the Access token contains a new context.

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:

...

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

...

As of Keycloak version 1.8.40, a list of the top-level roles for each available context are is given in the “roles element“. Each top-level role are is expanded to a set of privileges. This mapping can be 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. e. g.:The example request and response shown below illustrate the concept and are not intended to be normative, complete or kept up-to-date.

Groups
Code Block
languagejs
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",
        ...
    ],
    ...
}

...

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


Parameter name

Description

client_id

Required. The OAuth2 client id

grant_type

Required. Fixed to the value of the of ‘refresh_token’

refresh_token

Required. The refresh token of the current session

care_team_id (context)

Optional. A valid absolute FHIR URI pointing to a Careteam resource. This adds implicit organization context given the organization constraint in the OIO BPP structure

organization_id (context)

Optional. A valid absolute FHIR URI pointing to an Organization resource

episode_of_care_id (context)

Optional. This adds implicit patient context. A valid absolute FHIR URI pointing to an Episode of Care resource

patient_id (context)

Optional. A valid absolute FHIR URI pointing to a Patient resource


Example: Access token with context

...