New Feature Request
Summary
This feature request describes a new GSSP that can add an additional authentication cycle over OIDC via an OIDC provider. A user that logs on to an that is subject to a policy between its IdP and that SP must perform an additional authentication over OIDC at another IdP. The claims returned from the stepup authentication are merged with the attributes from the first authentication step.
The initial reason for this request is an OIDC provider is DEZI, ‘De Zorg Identiteit’, described further on.
If this feature request can be created in a generic fashion, it might better be referred to as GSSP/OIDC or similar.
Background: DEZI
DEZI is short for ‘DE Zorg Identiteit’, the new obligatory Identity Provider in the Netherlands for healthcare professionals. According to the new DEZI law, applications that contain sensitive patient data may only be accessed with a DEZI Identity. The identities need to be verified at EIDAS level ‘high’ (LoA=3). Employees are can self-register or registered by their organization and their profile is linked to their health care competence. A user can have multiple profiles, if affiliated to multiple health care organizations or fulfilling multiple roles.
Health care applications need to comply to strict NEN standards when it comes to authentication, authorization and auditing related to the DEZIdentity.
Applications that need to authenticate users against DEZI act as OIDC client towards DEZI. DEZI exposes itself as an OIDC provider in the form of a service called the ‘DEZI Ontkoppelpunt’. It presents the user with a choice of authentication methods and redirects the user to the corresponding authentication method supplier, such as DigiD.
Proposed Solution
Use Case: StepUp towards DEZI via OIDC
OpenConext is the basis for the federation called ‘govConext’ between public healthcare organizations and health application service providers (governmental, public as well as commercial). But Identity Providers may use StepUp also without OpenConext and loop in the DEZI authentication when needed.
The use case adds a few additional steps in the authentication flow between IdP, OpenConext and SP. A comprehensive overview of the steps is shown in the table futheron.
End users use their browser and MUST first browse to the SP [Flow step #1] via OpenConext [Flow step #2] as this is already the case within the govConext federation. The federation redirects via the WAYF towards the IdP and the user logs in [Flow step #3]. This way, specific attributes/claims from the IdP [Flow step #4] can be later be passed on to the SP for authorization that DEZI cannot provide. Also, this prevents additional connections that SP’s need to establish towards DEZI, besides the existing govConext trust relationships.
When a higher LoA is required, a trigger MUST be able to be created that loops in the new StepUp/DEZI GSSF [Flow step #5]. The DEZI number that was part of the claim set of the first login step between IdP and SP is used as identifier towards the DEZI “Ontkoppelpunt”.
The Ontkoppelpunt presents a WAYF-like page to select the applicable profile and choice of authentication method. Depending on which method provider the user has pre-registered with, the user chooses this provider. After a redirect, the user logs in with the Authentication method supplier (‘middelenleverancier’) [Flow step #6,7]. If the authentication is successful, the ‘Ontkoppelpunt’ returns an encrypted token towards StepUp that includes a ‘DEZI profile’ that consists of a triplet of the DEZI-ID, role code and organization code [Flow step #8].
Based on agreements (to be) established) between the IdP, the federation partner (govConext) and DEZI, the GSSF MUST be allowed to decrypt the payload.
The GSSP hands over the claims to the ongoing authentication flow and the claims are appended to the claims that were already gathered from the IdP.
All claims are transported to the SP. The user is logged in and the IdP-related claims as well as the DEZI claims are known to the SP [Flow step #9].
| UX? | Description | New?
-- | -- | -- | --
1 | | User surfs to webapplication at SP |
2 | UX | SP redirects to OpenConext WAYF |
3 | UX | OpenConext redirects to IdP, user logs in at own organization |
4 | | IdP sends browser back to OpenConext, including additional specific attributes |
5 | UX | OpenConext redirects to DeZI “Ontkoppelpunt” WAYF | New
6 | UX | DEZI redirects to authentication method supplier, user logs in | New
7 | | Authentication method supplier sends browser back to DEZI | New
8 | | DEZI sends browser back to OpenConext including DEZI profile | New
9 | UX | OpenConext supplies DEZI profile and IdP claims to SP, user is logged in |
Topology
The functional decomposition, building blocks and their relations are depicted in the diagram below. The flow is sketched in the architecture as well.
SSO
SP’s that connect directly to DEZI via OIDC are not allowed to support Single Sign On (SSO). If agreements are in order, within the federation SSO COULD be supported, as per the wish of many user groups. However, certain user groups need to switch DEZI profile within an application, so they need to be able to re-login, in which case SSO is not desirable.
To be discussed: Is SSO configurable per IdP? Per SP? Per other means in PDP maybe?
GSSP registration
There is no self-registration or RA involved, the trigger to loop in DEZI is set in a PDP in relation between IdP and SP including a check whether the DEZI-number is included in an IdP-attribute.
- Design: [Link to Figma/Screenshots]
On the SP side, after the first login step, the user is redirected to DEZI and and the GUI elements of DEZI apply. After those, the user returns to the SP. No interaction with StepUp is expected.
- Impact: Does this affect existing APIs or UI components?
To be investigated
Developer Checklist
To be completed by the developer during implementation.
Testing and QA
Describe how to verify and test this change.
Test Environment and Setup
- Point to [URL/Branch]
- Use account with [Role/Permissions]
Test Checklist
Extra Information
Add any other context, related issues, or technical notes here.
New Feature Request
Summary
This feature request describes a new GSSP that can add an additional authentication cycle over OIDC via an OIDC provider. A user that logs on to an that is subject to a policy between its IdP and that SP must perform an additional authentication over OIDC at another IdP. The claims returned from the stepup authentication are merged with the attributes from the first authentication step.
The initial reason for this request is an OIDC provider is DEZI, ‘De Zorg Identiteit’, described further on.
If this feature request can be created in a generic fashion, it might better be referred to as GSSP/OIDC or similar.
Background: DEZI
DEZI is short for ‘DE Zorg Identiteit’, the new obligatory Identity Provider in the Netherlands for healthcare professionals. According to the new DEZI law, applications that contain sensitive patient data may only be accessed with a DEZI Identity. The identities need to be verified at EIDAS level ‘high’ (LoA=3). Employees are can self-register or registered by their organization and their profile is linked to their health care competence. A user can have multiple profiles, if affiliated to multiple health care organizations or fulfilling multiple roles.
Health care applications need to comply to strict NEN standards when it comes to authentication, authorization and auditing related to the DEZIdentity.
Applications that need to authenticate users against DEZI act as OIDC client towards DEZI. DEZI exposes itself as an OIDC provider in the form of a service called the ‘DEZI Ontkoppelpunt’. It presents the user with a choice of authentication methods and redirects the user to the corresponding authentication method supplier, such as DigiD.
Proposed Solution
Use Case: StepUp towards DEZI via OIDC
OpenConext is the basis for the federation called ‘govConext’ between public healthcare organizations and health application service providers (governmental, public as well as commercial). But Identity Providers may use StepUp also without OpenConext and loop in the DEZI authentication when needed.
The use case adds a few additional steps in the authentication flow between IdP, OpenConext and SP. A comprehensive overview of the steps is shown in the table futheron.
End users use their browser and MUST first browse to the SP [Flow step #1] via OpenConext [Flow step #2] as this is already the case within the govConext federation. The federation redirects via the WAYF towards the IdP and the user logs in [Flow step #3]. This way, specific attributes/claims from the IdP [Flow step #4] can be later be passed on to the SP for authorization that DEZI cannot provide. Also, this prevents additional connections that SP’s need to establish towards DEZI, besides the existing govConext trust relationships.
When a higher LoA is required, a trigger MUST be able to be created that loops in the new StepUp/DEZI GSSF [Flow step #5]. The DEZI number that was part of the claim set of the first login step between IdP and SP is used as identifier towards the DEZI “Ontkoppelpunt”.
The Ontkoppelpunt presents a WAYF-like page to select the applicable profile and choice of authentication method. Depending on which method provider the user has pre-registered with, the user chooses this provider. After a redirect, the user logs in with the Authentication method supplier (‘middelenleverancier’) [Flow step #6,7]. If the authentication is successful, the ‘Ontkoppelpunt’ returns an encrypted token towards StepUp that includes a ‘DEZI profile’ that consists of a triplet of the DEZI-ID, role code and organization code [Flow step #8].
Based on agreements (to be) established) between the IdP, the federation partner (govConext) and DEZI, the GSSF MUST be allowed to decrypt the payload.
The GSSP hands over the claims to the ongoing authentication flow and the claims are appended to the claims that were already gathered from the IdP.
All claims are transported to the SP. The user is logged in and the IdP-related claims as well as the DEZI claims are known to the SP [Flow step #9].
| UX? | Description | New?
-- | -- | -- | --
1 | | User surfs to webapplication at SP |
2 | UX | SP redirects to OpenConext WAYF |
3 | UX | OpenConext redirects to IdP, user logs in at own organization |
4 | | IdP sends browser back to OpenConext, including additional specific attributes |
5 | UX | OpenConext redirects to DeZI “Ontkoppelpunt” WAYF | New
6 | UX | DEZI redirects to authentication method supplier, user logs in | New
7 | | Authentication method supplier sends browser back to DEZI | New
8 | | DEZI sends browser back to OpenConext including DEZI profile | New
9 | UX | OpenConext supplies DEZI profile and IdP claims to SP, user is logged in |
Topology
The functional decomposition, building blocks and their relations are depicted in the diagram below. The flow is sketched in the architecture as well.
SSO
SP’s that connect directly to DEZI via OIDC are not allowed to support Single Sign On (SSO). If agreements are in order, within the federation SSO COULD be supported, as per the wish of many user groups. However, certain user groups need to switch DEZI profile within an application, so they need to be able to re-login, in which case SSO is not desirable.
To be discussed: Is SSO configurable per IdP? Per SP? Per other means in PDP maybe?
GSSP registration
There is no self-registration or RA involved, the trigger to loop in DEZI is set in a PDP in relation between IdP and SP including a check whether the DEZI-number is included in an IdP-attribute.
On the SP side, after the first login step, the user is redirected to DEZI and and the GUI elements of DEZI apply. After those, the user returns to the SP. No interaction with StepUp is expected.
To be investigated
Developer Checklist
To be completed by the developer during implementation.
Testing and QA
Describe how to verify and test this change.
Test Environment and Setup
Test Checklist
Extra Information
Add any other context, related issues, or technical notes here.