...
Authentication and authorization by two Authorization Service (AS) Keycloak instances issuing JSON web tokens (JWT)
One for the Administrative Domain, Clinical Domain and Service, Support & Logistics (SSL) Domain, split in:
realm ehealth - for employee (clinical) login
realm nemlogin - for citizen login
One for the Service, Support & Logistics (SSL) Domain with
realm ssl - for SSL supplier employee login
Federated Authentication (and sometimes Federated Authorization)
For realm nemlogin: Federated using SAML to Nemlogin
For realm ehealth: Federated using OIOSAML to SEB (in Danish: Sundhedsvæsenets Elektroniske Brugerstyring shortened SEB) which is a common platform for user administration of the solutions provided by the National Health Data Authority
Federated to Municipal IdPs through the IdP proxy KOMBIT Context Handler for municipal users
Federated to Regional IdPs for regional users
Authorization based on externally known system roles, organisational context and possibly care team context
For realm ssl: Federated to SSL Supplier IdPs
Client use based on OpenID Connect 1.0 Authentication Code Flow with PKCE
Access Control enforced in eHealth services
Based on Role Based Access Control (RBAC) on privilege level
Mapping of externally known system roles to privileges
Based on Attribute Based Access Control (ABAC)
Using special contexts selected and contained in JWT
...
Provide a homogenous interface from its federated IdP's towards the eHealth Infrastructure
Doing the actual federation between the regional instances and the municipal instances
...
...
Login and security flow
When looking at the eHealth Infrastructure from the outside, the login flow looks like a regular OIDC login flow whereas the internal trust and federation is actually based on SAML. The AS used in the eHealth Infrastructure seamlessly bridges these security protocols - thereby making it easier for clients to the eHealth Infrastructure to gain the needed federated access to the actual services. As depicted in the diagram, the "User application" initiates the login flow with the infrastructure but is actually redirected to federated services. The flow is as follows:
The AS supports login using OpenID Connect "code flow" while NemLogin and SEB supports OIO SAML.
The AS bridges these security flows by sending back a redirection if no token is provided when interacting with the eHealth Infrastructure (NemLogin and SEB each have their own security realm in the AS meaning that the redirection logic is unambiguously).
The sequence of redirects (and SAML AuthRequests/Responses) that takes place between the app and its federated endpoint, before the AS is finally invoked with a SAML AuthResponse, is not of concern to the eHealth Infrastructure (but in the case of SEB, it probably involves redirects from SEB back to the users own IdP and back again). See Login for details.
While NemLogin provides details on the identity of the citizen such as name and civil registration number (the authentication part), SEB also provides details on the user in regards to what roles that apply (both authentication and authorization).
It is beyond the scope of the eHealth Infrastructure how and when these roles are applied in the federated setup. It is expected that the authorization part is governed by the IdP itself).
As no roles are issued from NemLogin, it means that citizens by default can only read data marked as theirs/involving them, with a few exceptions. Users (clinical users) however are provided with roles (from SEB or the IdP) scoped within an organization or a careteam (a careteam, in short, is a set of clinical users that provides services to a citizen. Users in careteams are not restricted to origin from the same region/municipality). Users can be in multiple careteams at the same time.
The OIO SAML part of the flow and the requirements to SAML assertions can be found on the pages Login and Authentication and authorization. These pages should be inspected by administrators of the municipality IdP's and regional IdP's.
...