Page Comparison

...

• Authentication and authorization by two Authorization Service (AS) Keycloak instances issuing JSON web tokens (JWT)

  • One for the Administrative Domain and Clinical , 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

• Token based security

• Client use based on OpenID Connect 1.0 Authentication Code Flow with PKCE

  • Client types, login, and requirements

  • Selecting and switching contexts in JWT

  • Token exchange

• 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

• Token based security

• Client use based on OpenID Connect 1.0 Authentication Code Flow with PKCE

  • Client types, login, and requirements

  • Selecting and switching contexts in JWT

  • Token exchange

• 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

...