Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
            • SWR-001- Users of the REST API can log in and receive an access token
            • SWR-002- The REST API enforces HTTPS for all communications to ensure data security
            • SWR-003- The REST API implements rate limiting to prevent abuse
            • SWR-004- The REST API verifies the access token for every request to secure endpoints
            • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
            • SWR-006- The REST API only accepts and outputs images in Base64 format
            • SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
            • SWR-008- The user's password is stored in the database as a hashed password
            • SWR-009- New users of the device are only created by an internal user registration service
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • ignore-this
  • SWR-001- Users of the REST API can log in and receive an access token

SWR-001- Users of the REST API can log in and receive an access token

Internal IDSWR_001
TitleUsers of the REST API can log in and receive an access token
CategorySECURITY, REGULATORY
ImportanceCRITICAL
SystemREST API
Editor(s)Alejandro Carmena Magro, JD-017
SupervisorAlfonso Medela , JD-005
Approval
Created at17 Jun 2024

Description​

The REST API provides an endpoint for user authentication. Users can log in by providing their credentials (username and password). Upon successful authentication, the API returns an access token (e.g. a JSON Web Token) that can be used for subsequent requests to authorize access to protected resources.

Activities generated​

  • Development of the login endpoint.
  • Implementation of secure password handling and storage.
  • Generation and management of web access tokens.

Implements user needs​

This requirement ensures that users can securely log in to the system and obtain an access token, enabling them to perform authorized actions within the device UI. It addresses the critical need for secure user authentication in the system.

Regulatory requirements​

1.1: The device shall be compliant with MDR 2017/745, Annex I, point 17.2, 17.4, 18.8, 23.4(ab).

Causes failure modes​

  • Incorrect handling of user credentials may lead to potential leaks and other security vulnerabilities.
  • Failure to generate or validate access tokens could prevent users from accessing the system.
  • Insufficient protections against brute force attacks (e.g., not implementing rate limiting and account lockout mechanisms), allowing attackers to guess passwords.
  • Failure to properly handle token expiration, leading to users being logged out unexpectedly or able to use expired tokens.
  • Insufficient encryption or lack of HTTPS, making the login process susceptible to MITM attacks.
  • Lack of mechanisms to prevent replay attacks, where an attacker intercepts and reuses a valid token.
  • Providing overly detailed error messages that could give attackers clues about the system's security mechanisms.

Tested by software tests​

  • PLAN_001: User submits credentials to receive a token
  • PLAN_002: Token expiration in user authentication process
  • PLAN_003: Account lockout for user authentication

In addition to system-level tests, this requirement has also been verified through unit tests for each component of the login process and integration tests to ensure all components communicate successfully when a request is sent to the authentication endpoint.

Implements risk control measures​

  • Tokens have a short expiration time to limit the window of vulnerability if a token is compromised. A refresh token mechanism is implemented to obtain new tokens securely.
  • Implement token revocation mechanisms to invalidate tokens when necessary, such as during logout or after detecting suspicious activities.
  • Implement rate limiting on login attempts to prevent brute force attacks.
  • Account lockout mechanisms are in place to temporarily disable accounts after a certain number of failed login attempts.
  • Implement secure error handling to ensure that error messages do not disclose sensitive information that could be useful to attackers.
  • Implement logging and monitoring to detect and respond to suspicious activities in real-time.

Acceptance criteria​

  • Users can successfully log in with valid credentials and receive an access token.
  • The system rejects invalid login attempts with appropriate error messages.
  • Access tokens are generated securely and have a configurable expiration time.

Constraints​

  • The login process must comply with relevant security standards and regulations (e.g., GDPR)

Dependencies​

  • User management system for validating credentials.
  • Secure storage system (e.g., Database) for user passwords.

Performance considerations​

  • The login endpoint must handle a high number of concurrent requests efficiently.
  • Access token generation and validation should be optimized for performance.

Additional notes​

Future enhancements may include multi-factor authentication (MFA) as an additional layer of security, requiring users to provide a second form of verification in addition to their password.

Revision history​

VersionDateAuthorDescription
Previous
REQ_013 The user receives the pixel coordinates of possible ICD categories
Next
SWR-002- The REST API enforces HTTPS for all communications to ensure data security
  • Description
  • Activities generated
  • Implements user needs
  • Regulatory requirements
  • Causes failure modes
  • Tested by software tests
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
  • Revision history
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)