Authorization Flow
When a client starts an OIDC Authorization Code Flow for a municipal user, it uses SEB and KOMBIT Context Handler and goes through the following federation process.
The sequence diagram for clinicians' logins, explained in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/101122074/Login#Clinical-logins, 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:
The KOMBIT Context Handler created a SAML AuthnResponse based on registrations stored in the KOMBIT user administration system KOMBIT STS Administration (STS Admin or DK Admin for short).
The eHealth Infrastructure-hosted SAML Proxy - This service does tasks like substituting and translating KOMBIT-flavor SAML Attributes to ensure uniform OIOSAML OIO-BPP Attributes are provided to SEB. It also enhances OIOSAML Attributes by adding the employee's CPR number, obtained from the KOMBIT FK Organisation system.
Sundhedsvæsenets Elektroniske Brugerstyring (SEB) - This is the shared user administration platform for the Danish healthcare sector.
The eHealth Authorization Service (KeyCloak) - When the KOMBIT NSIS Context Handler can connect directly with SEB and the SAML-proxy is removed from the flow. The KeyCloak service shall then modify and adapt KOMBIT-style SAML Attributes to ensure they match the uniform OIOSAML OIO-BPP Attributes used.
Registrations Required in Municipal KOMBIT Systems
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 |
|---|---|
Usersystem (Danish: Brugervendt system) | An IT system that provides an access-controlled user interface, A usersystem registered in the KOMBIT STS admin enables it to use KOMBIT systems for access control of end-users. |
Usersystem 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:
|
eHealth Infrastructure User-systems
For the KOMBIT external test environment the following eHealth environments are registered as user-facing systems, and thereby use KOMBIT systems for access control:
Usersystem in FK Administration | System | |
|---|---|---|
| 1 | FUT - SAML Proxy (devtest) | FUT saml-proxy for the internal Systematic Test Environment. |
| 2 | FUT - SAML Proxy (inttest) | FUT saml-proxy for the eHealth Internal Test Environment |
| 3 | FUT - SAML Proxy (exttest) | FUT saml-proxy for the eHealth External Test environment (exttest) and external development environment (devenvcgi). |
| 4 | FUT - SAML Proxy (test002) | FUT saml-proxy for the eHealth Education environment (TEST002) |
| 5 | FUT - SAML Proxy (preprod) | FUT saml-proxy for the eHealth pre-production environment |
| 6 | “T-SEB” Being used in the future when SEB and ContextHandler directly connected. The name not known by Systematic. | T-SEB for all eHealth test (incl. pre-prod) environments. |
Similar registrations are made in the KOMBIT STS Admin in the KOMBIT production environment, only here the sole SAML Proxy is in the eHealth Infrastructure production environment (PROD).
Data constraints (Danish: “data afgrænsninger”)
The data constraints are which narrow the user system role. In eHealth Infrastructure, there are two data constraints in use:
CareTeam - a system-specific data constraint identifying a CareTeam. The optional for some user system roles, required for others (see below)
Organisation - Cross-cutting (data constraint) identifying Organisation from KOMBIT FK Organisation. This data constraint is defined and maintained outside eHealth.
The following screenshot shows the “Fælleskommunalt Administrationsmodul” user interface for creating data constraints and mandatory fields.
User-facing system | Data Contraint Name | EntityId (domain + “/constraint/”+ filter + version) | Syntax validation | |
|---|---|---|---|---|
| 1 | DEVTEST | Careteam |
| ([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})* |
| 2 | INTTEST | Careteam |
| ([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})* |
| 3 | EXTTEST, DEVENVCGI | Careteam |
| ([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})* |
| 4 | TEST002 | Careteam |
| ([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})* |
| 5 | PREPROD | Careteam |
| ([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})* |
| 6 | “T-SEB” Name not known by Systematic. | Careteam Does SEB require Data Constraint s names are prepended with “fut” or “eHealth” |
We assume constraint can reuse and have named as “FUT exttest” user-facing system. | ([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})* |
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 registered in KOMBIT STS Admin:
shall have an EntityId on the form:
<Domain>appended with<KOMBIT role name for the eHealth Infrastructure>and<version>(see below).can have (and should have) a name in Danish which is the Danish designation https://docs.ehealth.sundhed.dk/latest-released/ig/CodeSystem-ehealth-oio-bpp-roles.html for the corresponding eHealth Infrastructure OIO BPP system role.
<Domain>shall reflect the eHealth Infrastructure environment for registration in the KOMBIT STS Admin. The<Domain>shall be one of the following:
eHealth Infrastructure Environment | Domain | |
|---|---|---|
| 1 | INTTEST |
|
| 2 | EXTTEST, DEVENVCGI |
|
| 3 | TEST002 |
|
| 4 | PREPROD |
|
| 5 | PROD |
|
| 6 | “T-SEB” Name not known by Systematic |
Suggestion. |
In case of change in what eHealth Infrastructure environments shall support municipal federation of authentication and authorization, the above list needs to be updated. In addition, such a change needs to be implemented in the mapping performed by the SAML Proxy.
eHealth Infrastructure User system roles for FUT Proxy (exttest)
<KOMBIT role name for the eHealth Infrastructure> shall be one from the list below:
The table shows the KOMBIT user system role, the corresponding OIO BPP roles, and the possible data constraints and which are mandatory for “FUT Proxy (exttest)”.
KOMBIT user system roles for the eHealth Infrastructure | Data constraints (EXTTEST) | ||
|---|---|---|---|
STS Organisationsenhed | Careteam | ||
|
| Mandatory | |
|
| Mandatory | Mandatory |
|
| Mandatory | |
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | |
|
| Mandatory | |
|
| Mandatory | Mandatory |
|
| Mandatory | |
|
| Mandatory | Mandatory |
|
| Mandatory | |
|
| Mandatory | |
|
| Mandatory | |
|
| Mandatory | |
eHealth Infrastructure User system roles for FUT Proxy (prod)
The table shows the KOMBIT user system role, the corresponding OIO BPP roles, and what data constraints are possible and which are mandatory for “FUT Proxy (prod)”.
KOMBIT user system roles for the eHealth Infrastructure | Data constraints | ||||
|---|---|---|---|---|---|
Organisation | SOR Organisationsenhed | SSL Organisationsenhed | Careteam | ||
|
| Mandatory | Optional | ||
|
| Mandatory | Optional | Optional | |
|
| Mandatory | Optional | ||
|
| Mandatory | Optional | Optional | |
|
| Mandatory | Optional | ||
|
| Mandatory | Optional | ||
|
| Mandatory | Optional | Optional | |
|
| Mandatory | Optional | Optional | |
|
| Mandatory | Optional | Optional | |
|
| Mandatory | Optional | ||
|
| Optional | Optional | ||
|
| Mandatory | Optional | ||
|
| Optional | Optional | ||
|
| ||||
|
| Optional | Optional | ||
|
| Optional | Optional | ||
|
| Optional | Optional | ||
eHealth Infrastructure User system roles for T-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”.
When the SEB is used a user facing system, may not contain underscore, and names may be prepended “eHealth” or “FUT”.
KOMBIT user system roles for the eHealth Infrastructure Likely to be changed. To remove underscores and repent with “ehealth” or “fut”. | Data constraints | ||
|---|---|---|---|
Organisation
| Careteam | ||
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Mandatory |
|
| Mandatory | Optional |
|
| Mandatory | Mandatory |
|
| Mandatory | Mandatory |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
|
| Mandatory | Optional |
If the OIO BPP system roles system listed above deviate from the list in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/291176482/Tokens+Roles+and+RBAC+ABAC#Privilege-Roles , the above list needs to be updated.
In addition, such a change needs to be implemented in the https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2172125189/SAML+Proxy#Mapning-af-privilegier-og-constraints performed by the SAML Proxy.