/
Assisted Login for Citizens

Assisted Login for Citizens

  • Rough draft

    • Introduction

    The Assisted Login Feature makes it possible for citizens who do not have MitID to be logged in to the eHealth infrastructure.

    Instead of logging in via NemLog-in using MitID, a citizen can with the assistance of an employee, be logged in using only their CPR-number.

    The infrastructure provides a technical APIs for third party vendors. Third party vendors must implement API integration, user interfaces, and PIN handling in their application to support this feature.

    Usage

    Assisted login has 4 steps:

    1. An Employee starts an assisted login session for a citizen.

    2. The Citizen provides their CPR-number using a third party application.

    3. The Employee approves the citizens login attempt.

    4. The Citizen can now complete the login attempt, and is now authenticated.

    An employee can revoke an assisted login session at any point in time. If the citizen as completed step 4, revoking the assisted login session will also terminate the user session, meaning the citizen user will be logged out.

    An assisted login session will expire, if the 4 steps are not completed within a given time limit. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/edit-v2/4238671879#Time-Limits .

    Data and Audit Registration

    Access Consent Resource

    When an employee starts an assisted login session, the infrastructure will automatically create an Access Consent Resource (https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-access-consent.html ). This resource represents that the citizen have given consent to the employee to use assisted login.

    If the assisted login session is revoked the Access Consent Resource will have its status changed to REJECTED, and if the assisted login session is expired it will have its status changed to INACTIVE.

    Access Provenance Resource

    When the citizen completes step 4 and is logged in, the infrastructure will automatically create an Access Provenance Resource (https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-access-provenance.html ). This resource represents that the citizen has logged in using Assisted Login.

    Auditlog

    All user actions related to assisted login are logged in the infrastructures internal auditlog.

    Security Concerns

    Information disclosure

    Citizens need only provide a CPR number when using assisted login. To prevent the infrastructure from disclosing personal information, or making it possible to derive such information, the assisted login feature is designed to return an identical response regardless of the CPR number provided.

    This means the infrastructure's responses and behavior cannot reveal anything, explicitly or implicitly, about the provided CPR number. Any deviation from this principle would constitute an information disclosure vulnerability.

    To uphold this, the assisted login feature behaves identically from the citizen's point of view until the employee has approved the login attempt. The trade-off is a more limited user experience for citizens: no information about the status of a login attempt is available until it is either approved or expired.

    Third-party vendors should compensate for this limitation by providing clear and precise guidance to both citizen and employee users. Third-party vendors must also ensure that there is no information disclosure vulnerabilities in their implementation.

    Verifying identity

    The Assisted Login feature does not itself verify the identity of the citizen logging in. Therefore:

    It is the responsibility of the employee who assists the citizen, to verify that the person being logged in, is the actual citizen.

    The infrastructure does not provide any way of verifying a citizens identity other than via NemLog-in. The employee must therefore use other means outside of the infrastructure.

    The infrastructure provides the level of assurance in the users access token. See: https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/291176482/Token+Based+Security#Authentication-Context-Class-Reference-(ACR)-for-Patients

    Time Limits

    To mitigate the risk posed by the fact that the assisted login feature only requires a CPR-number, and that there is no technical identity verification, the infrastructure imposes time limits on the login attempts.

    Assisted login can be divided into 3 phases, each having their own time limit:

    1. Initialization phase (24 hours)

    2. Completion phase (24 hours)

    3. Use phase (determined by PIN expiry)

    The initialization phase begins when the employee starts the session, and ends when the citizen provides their CPR-number (Step 1 - 2).

    The completion phase begins then the citizen provides their CPR-number, and ends when the citizen completes the login attempt (Step 2 - 4).

    The use phase begins when the citizen completes the login attempt (Step 4). When the login attempt is completed and the user is authorized, the infrastructures usual user session and PIN time limits apply. This means that a citizen user can use their user session as long as it is valid and their PIN is not expired.

    Time limits are configurable in the infrastructure. The values on this page reflects the current configuration in production. The actual expiry times are available in the APIs, and it should therefore not be necessary for third party applications to be aware of the actual time limits at runtime.

    Getting Started

    To get started with assisted login as a third party vendor, you need the following setup

    Test environments

    The API documentation for developers can be found here: https://ehealth-dk.atlassian.net/wiki/x/AYCH-/

    Production environment

    When going to production, make sure the service account and client whitelisting is also in production, and that the intended employee users have the Login Assistor role.

    • Getting a service account and whitelisting in production will be handled in the same service request for the test environment.

    • User roles must be configured by the administrators in the local user administration systems of regions and municipalities.