...

1. 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).

2. 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.

3. Sundhedsvæsenets Elektroniske Brugerstyring (SEB) - This is the shared user administration platform for the Danish healthcare sector.

4. 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.

...

KOMBIT Terms and Concepts

...

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

Registrations Required in Municipal KOMBIT Systems

eHealth Infrastructure as User-systems

For the KOMBIT external test environment the The eHealth test environments use KOMBIT Context Handler for access control and therefore are registered as user-facing systems in the FK Administration system

The following eHealth environments are registered as user-facing systems , and thereby use KOMBIT systems for access controlin the KOMBIT external test:

Similar registrations are made FUT-S has created similar registrations in the KOMBIT STS Admin FK Admininistratino in the KOMBIT production environment, . This only here has the sole SAML Proxy is in for 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 - CrossOrganisation—This is a cross-cutting (data constraint) identifying Organisation from KOMBIT FK Organisation. This data constraint is defined and maintained outside eHealth.

...

...

• 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 Danish name, the Danish designationhttps://docs.ehealth.sundhed.dk/latest-released/igfhir/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:

...

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”.

...

...

To allow regional and municipal employees to access national healthcare solutions from the FUT Infrastructure their CPR information is required. The Infrastructure receive CPR for regional employees directly from SEB, however, for municipal employees, CPR must be obtained from Kombit FK Org. This is done through the internal OS2Sync service* running on the Infrastructure. OS2Sync uses BrugerService and PersonService version 6 of Kombit FK Org Version 3.2.

*Image The image used on the FUT Infrastructure can be found on dockerhub and the source code on github GitHub OS2Sync.