/
Federated Authentication and Authorization for Municipal Users

Federated Authentication and Authorization for Municipal Users

Description of federated authentication and authorization for Municipal Users using SEB and KOMBIT ConcextHandler.

 

Authentification Flow

The client starts the login of municipal users by starting an OIDC Authentification Code Flow. The eHealth authentication server (KeyCloak) goes through a federation process and uses SEB and KOMBIT Context Handler for login in the user.

 

Municipial login flow.png

The sequence diagram for clinicians' logins, explained in Guide; Client Application Login and Logout to eHealth Infrastructure | Clinical logins. This shows how the OIDC Authorization Code Flow is redirected through a series of steps involving OIOSAML-based AuthNRequest and AuthNResponse.

Here's a summary of the responsibilities of the services involved:

  1. The eHealth Authorization Service (KeyCloak) - Forwards the login request as SAML AuthNRequest to the SEB and receives the SAML response from SEB. The KeyCloak service modifies and adapts KOMBIT-style SAML Attributes to ensure they match the uniform OIOSAML OIO-BPP Attributes used.

  2. Sundhedsvæsenets Elektroniske Brugerstyring (SEB) - This is the shared user administration platform for the Danish healthcare sector. This forwards or federate municipality users login to the KOMBIT Context Handler.

  3. The KOMBIT Context Handler forwards login to municipality IdP and creates a SAML AuthnResponse based on registrations stored in the KOMBIT user administration system STS Administration (or STS Admin or FK Admin for short).

KOMBIT Terms and Concepts

The English terms used in the following do not constitute official, KOMBIT translations of the Danish terms used throughout KOMBIT documentation and systems. The Danish terms stem from section 3 in Brugervejledning til Administrationsmodulerne for leverandører.

The following terms are used in registrations in “Fælleskommunalt Administrationsmodul” (KOMBIT STS Admin):

Term

Description

Term

Description

User system

(Danish: Brugervendt system)

An IT system that provides an access-controlled user interface,
accessed via a browser. That is, a system directly used by an end-user.

A user system registered in the KOMBIT STS admin enables it to use KOMBIT systems for access control of end-users.

User system role

(Danish: Brugersystemrolle)

Grouping of rights or permissions that define access and access restrictions to a specific user-facing system

Data constraint

(Danish: Dataafgrænsning)

Restriction of a “user system role”, which narrows the system role's field of action

Job function role

(Danish: Jobfunktionsrolle)

Grouping of user system roles for an authority (e.g. municipality) used by the authority to assign access to the user.

Each municipality shall maintain a set in KOMBIT STS Admin.

Concerning eHealth Infrastructure, the job function role should comprise:

  • A collection of user system roles

  • An Organisation identifier

  • A possible CareTeam identifier

Registrations Required in Municipal KOMBIT Systems

eHealth Infrastructure as User-systems

The eHealth Infrastructure uses the KOMBIT Context Handler for access control.

Therefore the eHealth test environments are registered as user-facing systems in the FK Administration system (https://admin-test.serviceplatformen.dk/).

As the login flows through the SEB, the management of the eHealth test environments is managed by Sundhedsdatastyrelsen (Danish Health Authority).

The eHealth test environments are registered as one user-facing system in the KOMBIT external test and login goes through T-SEB for all eHealth test environments (incl. pre-prod).

The name of the user system is unknown to Systematic.

A similar registration in the KOMBIT FK Administration in the KOMBIT production environment.

Data constraints (Danish: “data afgrænsninger”)

The data constraints narrow the user system role. In eHealth Infrastructure, there are two data constraints in use:

  • Organisation - This is a cross-cutting data constraint identifying an Organisation from KOMBIT FK Organisation. This data constraint is defined and maintained outside eHealth.

  • CareTeam - This is a system-specific data constraint identifying a CareTeam. This constraint is optional for some user system roles and required for others (see below). The data constraint is defined as follows:

    • Data Constraint Name: CareTeam

    • EntityId: http://<domain>/constraints/<filtername>/<version>

      • domain: ehealth.seb.dk

      • filtername: careteam

      • version: 1

    • type: Syntax validation

    • ([0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[0-9a-f]{4}-[0-9a-f]{12})+(,\s*[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[0-9a-f]{4}-[0-9a-f]{12})*

The following screenshot shows the “Fælleskommunalt Administrationsmodul” user interface for creating data constraints and mandatory fields.

image-20240126-160759.png

KOMBIT User system roles for the eHealth Infrastructure

The following screenshot shows the “Fælleskommunalt Administrationsmodul” user interface for creating user system roles and mandatory fields.

User system roles for the eHealth Infrastructure are registered in KOMBIT STS Admin:

Mapping between KOMBIT user system role and OIO BPP role

The KOMBIT user system role has a different format than the eHealth Infrastructure OIO BPP system roles.

The following table shows the KOMBIT user system role and the corresponding OIO BPP roles.

eHealth Infrastructure user system role (KOMBIT form)

eHealth Infrastructure user system role (KOMBIT form)

/roles/usersystemrole/order_placer/1

urn:dk:sundhed:ehealth:role:order_placer

/roles/usersystemrole/citizen_enroller/1

urn:dk:sundhed:ehealth:role:citizen_enroller

/roles/usersystemrole/careteam_administrator/1

urn:dk:sundhed:ehealth:role:careteam_administrator

/roles/usersystemrole/incident_reporter/1

urn:dk:sundhed:eHealth:role:incident_reporter

/roles/usersystemrole/clinical_viewer/1

urn:dk:sundhed:eHealth:role:clinical_viewer

/roles/usersystemrole/clinical_supporter/1

urn:dk:sundhed:eHealth:role:clinical_supporter

/roles/usersystemrole/monitoring_assistor/1

urn:dk:sundhed:eHealth:role:monitoring_assistor

/roles/usersystemrole/monitoring_adjuster/1

urn:dk:sundhed:eHealth:role:monitoring_adjuster

/roles/usersystemrole/report_user/1

urn:dk:sundhed:ehealth:role:report_user

/roles/usersystemrole/clinical_administrator/1

urn:dk:sundhed:eHealth:role:clinical_administrator

/roles/usersystemrole/service_and_logistics/1

urn:dk:sundhed:eHealth:role:service_and_logistics

/roles/usersystemrole/questionnaire_editor/1

urn:dk:sundhed:eHealth:role:questionnaire_editor

/roles/usersystemrole/incident_manager/1

urn:dk:sundhed:eHealth:role:incident_manager

/roles/usersystemrole/terminology_administrator/1

urn:dk:sundhed:eHealth:role:terminology_administrator

/roles/usersystemrole/ssl_catalogue_responsible/1

urn:dk:sundhed:eHealth:role:ssl_catalogue_responsible

/roles/usersystemrole/ssl_catalogue_annotator/1

urn:dk:sundhed:eHealth:role:ssl_catalogue_annotator

/roles/usersystemrole/ssl_contract_responsible/1

urn:dk:sundhed:eHealth:role:ssl_contract_responsible

eHealth Infrastructure user system roles for T-SEB and SEB (consolidated)

The table shows the KOMBIT user system role, the corresponding OIO BPP roles, and what data constraints are possible and which are mandatory for “T-SEB” and SEB.

KOMBIT user system roles for the eHealth Infrastructure

Data constraints

Organisation

http://sts.kombit.dk/constraints/orgenhed/1

Careteam

/roles/usersystemrole/order_placer/1

 

Mandatory

Mandatory

/roles/usersystemrole/citizen_enroller/1

Mandatory

Mandatory

/roles/usersystemrole/careteam_administrator/1

Mandatory

Optional

/roles/usersystemrole/incident_reporter/1

Mandatory

Optional

/roles/usersystemrole/clinical_viewer/1

Mandatory

Mandatory

/roles/usersystemrole/clinical_supporter/1

Mandatory

Optional

/roles/usersystemrole/monitoring_assistor/1

Mandatory

Mandatory

/roles/usersystemrole/monitoring_adjuster/1

Mandatory

Mandatory

/roles/usersystemrole/report_user/1

Mandatory

Optional

/roles/usersystemrole/clinical_administrator/1

Mandatory

Optional

/roles/usersystemrole/service_and_logistics/1

Mandatory

Optional

/roles/usersystemrole/questionnaire_editor/1

Mandatory

Optional

/roles/usersystemrole/incident_manager/1

Mandatory

Optional

/roles/usersystemrole/terminology_administrator/1

Mandatory

Optional

/roles/usersystemrole/ssl_catalogue_responsible/1

Mandatory

Optional

/roles/usersystemrole/ssl_catalogue_annotator/1

Mandatory

Optional

/roles/usersystemrole/ssl_contract_responsible/1

Mandatory

Optional

If the OIO BPP system roles system listed above deviate from the list described inToken Based Security | Privilege Roles, the above list needs to be updated.

In addition, such a change needs to be implemented in the eHealth KeyCloak.

Getting municipal employee CPR

To allow regional and municipal employees to access national healthcare solutions from the FUT Infrastructure their CPR information is required.

Related content

Security Mechanisms
Security Mechanisms
More like this
Managing and Using Organization, CareTeam and Practitioner
Managing and Using Organization, CareTeam and Practitioner
Read with this
Federated Authentication and Authorization for Municipal and Regional Users
Federated Authentication and Authorization for Municipal and Regional Users
More like this
Services and Endpoints
Services and Endpoints
Read with this
Federated Authentication and Authorization for Regional Users
Federated Authentication and Authorization for Regional Users
More like this
Creating and Maintaining Measurement Ranges
Creating and Maintaining Measurement Ranges
Read with this