Summary
User accounts are required to access ClinSpark. To authorize access to certain studies and features, a user account is typically assigned one to many Sites, Studies, and Roles.
When creating a new user, the organization’s authentication rules set in Administration > General Settings are inherited by default. Password Can Expire and Session Timeout Minutes can be overridden at the per-user level.
Users can be assigned multiple roles and authorization is an aggregate of all the roles. Once assigned, the user will be authorized to perform any function within those roles.
Users can be restricted to one or more studies and/or sites, which facilitates controlled access to users internal or external to the customer organization.
The Administration > Users component provides capabilities for locating, exporting and managing users within an organization.
Roles & Studies
Newly created users will have no roles assigned. A user must be assigned at least one role to be able to log into ClinSpark.
Users can be restricted to 0 or more studies and sites. By default, users can interact with any study and site in the system unless defined otherwise by their account configuration.
User management features are designed to meet CFR 21 Part 11 guidelines:
Sessions timeout at configurable interval
Passwords and accounts can be configured for expiration
Failed login attempts are tracked; user can be locked out after configurable number of failures and alerts are sent when failures threshold is reached
Lockout duration is configurable
Passwords ‘in plain text’ are not stored in the database, but rather a salted hash is stored
Password Policy
ClinSpark allows organizations to configure certain password policies. These are configured with Administration > General Settings and are enforced across all user accounts:
Password Minimum Length
Password Expire Days (number of days until user forced to change password)
Alphanumeric passwords (passwords must contain digits and letters)
Special character passwords (must contain one or more:
!#"$%&'()*+,-./:;<=>?@[]^_`{|}~)Prevent re-use of previous account passwords (configurable system setting)
Password reuse
The system allows organizations to optionally enforce a strict password re-use policy through a controlled system setting. This setting helps follow a security best practice to mitigate vulnerabilities that are caused by password reuse. If this setting is not used, the default behavior is that users may not re-use their immediate past password. However, they may re-use use older passwords.
If the setting value is 1 or greater, ClinSpark will check prior account passwords against this configuration and prevent use of a password, if it was within the defined value.
This setting is enforced in workflows where a user resets their own password; either through their user profile, self-service password reset workflows, or a forced password reset during authentication (login) workflows.
For security purposes, this system setting is not enforced when an administrative user resets the password of another user account, through the Administration > Users component. This is to ensure that administrative users are not informed of or exposed to any prior passwords that may have been in use with a user account.
Password Managers
Password managers offer greater security and convenience for the use of passwords to access online services. Strong security is achieved principally through the capability of most password manager applications to generate unique, long, complex, easily changed passwords for all online accounts and the secure encrypted storage of those passwords.
We recognize and support of the use of password managers for users who are accessing ClinSpark on their own personal computing device. However, password managers may not be appropriate for use in all scenarios, such as a shared bedside data collection computer.
Users should discuss the use of password managers with their system administrators to understand if organization IS/IT policies are governing their use.
Password Reset Workflows
Password reset workflows are intended to be ‘self serve’ for users. When accounts are configured with an e-mail address, the password reset workflow is most commonly supported through that process.
However, there may be times when an administrative user needs to manually reset a password for a given user. To accomplish this, within the ‘Update User’ workflow, the two password fields must be supplied with a temporary password.
On save, users will see a message in ClinSpark that the password was updated, and, the ‘Password Expiration Date’ was also updated. This is by design, as ClinSpark is establishing this value to ensure that the next login attempt for that user forces them to update their password.
Once a user re-authenticates and updates their password, the expiration date will then change to whatever is established based upon system configuration.
The ‘Password Expiration Date’ field serves as an option for Admins to update after a password has been established (outside of reset workflow). Most commonly it’s used if an Admin wants to extend the current active password period for a given user, or remove it entirely.
Two Factor Authentication (2FA)
ClinSpark supports the ability to enable two factor authentication (2FA) for active users. This is an optional setting for all user accounts. Site administrators that have the ability to manage user accounts in the Administration > Users component can establish this setting new or existing accounts.
When applied, the setting will require the user to perform an additional authentication step upon login.
E-mail based 2FA workflows that contain authentication codes are only valid for a limited period of time, which is specified in the e-mail received.
The 2FA e-mail template is controlled by a system configuration and can be modified on request via the service desk, via IQVIA superadmin users.
Disabling SSO
When a ClinSpark instance is configured to use SSO, there are options that become available that can disable SSO authentication enforcement. This is a per-account configuration. Typically, we see customers using SSO to enforce authentication for most of their internal staff users, and setting up ClinSpark accounts for external users (such as sponsors or monitors) that do not enforce SSO authentication.
To learn more SSO setup and configuration, visit this article: Single Sign-on (SSO)
Within the account management screen, users can determine if SSO has been ‘disabled’ on an account.
When SSO is disabled for a given user account, the user will be allowed to authenticate into ClinSpark using their application username and password.
If SSO however is not disabled, ClinSpark will not allow that user to authenticate.
Locked accounts
When users fail to authenticate into ClinSpark after a number of attempts, their account is flagged as ‘Locked’. This locking mechanism is in place to protect ClinSpark environments from malicious authentication activities. When an account is locked, e-mail alerts are sent to defined recipients as configured in Administration > General Settings > Communications, so that appropriate actions can be taken to investigate and resolve any locked accounts.
ClinSpark allows for the following configurations:
Maximum Fail Attempts (maximum authentication failures before a user account is locked)
Lock Timeout Minutes (number of minutes user will be locked)
Lockout attempts are cumulative, and the period of time elapsed between them does not change what the current count is set to. The lockout attempt count resets only after a user has successfully logged into ClinSpark.
Once the configured ‘Maximum Fail Attempts’ count is reached, the account is locked and a lockout period is set; defined as ‘Locked Until’ date. This time period is based on the system configuration.
If during the lockout period a user does provide the correct username/password combo, they will see a message stating: The account has been locked due to excessive failed login attempts. If users however continue to fail logging in during the period their account status is locked, the ‘Locked Until’ date will continue to increase and be updated based on the most recent failed login attempt.
For increased security, a more specific lockout message is not displayed to users attempting to authenticate to avoid confirming existence of the user account or lockout period status.
Users with locked accounts have three options:
Wait the until the ‘Locked Until’ date passes and try again
Reach out to their ClinSpark system administrator to manually remove the locked status on their account
Successfully complete self-service password reset workflow
Self-service password reset helps ensure that legitimate users have a quick and secure way to get back into their ClinSpark account without having to wait for the lockout period to end or get in touch with a system administrator.
Audit events
Many actions related to user account management and access are audited. The following outlines all audit events.
When saving a new user, ClinSpark logs a Save audit type
When a user information update initiated by an administrator or user occurs, ClinSpark logs an Update audit type
When an administrator unlocks a given user, ClinSpark logs an Unlock audit type
When a user successfully authenticates, ClinSpark logs a Login audit type
When a user selects ‘log out’ feature from user menu, ClinSpark logs a Logout audit type
When a user fails to authenticate with correct password, this will produce a Login fail audit type
When a user changes their password or administrator changes user password, ClinSpark logs a Password Reset audit type
When a user attempts an action that they are not authorized for (accessing a URL a user’s role does not support), ClinSpark logs an Unauthorized User Action audit type
When adding a study to a user in order to restrict the user, ClinSpark logs an Add Study audit type; notes section will contain study name
When removing a study from a user in order to remove the user’s study restriction, ClinSpark logs a Remove Study audit type; notes section will contain study name
When adding a role to a given user, ClinSpark logs an Add Role audit type. The ‘notes’ section will contain the role description.
When removing a role from a given user, ClinSpark logs a Remove Role audit type. The ‘notes’ section will contain the role description.
When adding a study specific role, ClinSpark logs a Add Study Role audit type. The ‘notes’ will indicate which study and role was impacted.
When removing a study specific role, ClinSpark logs a Remove Study Role audit type. The ‘notes’ will indicate which study and role was impacted.
When adding a site, ClinSpark logs an Add Site audit type. The ‘notes’ section will contain the site name.
When removing a site, ClinSpark logs a Remove Site audit type. The ‘notes’ section will contain the site name.
When applying an eSignature, ClinSpark logs an eSignature audit type. The ‘notes’ section will contain the area where the eSignature was applied.
When an eSignature attempt fails, ClinSpark logs an eSignature Fail audit type. The ‘notes’ section will contain details aboutthe failure.
Audit types
A list of all the Audit types are in the drop down and are generated through various Audit Events.
Print User Barcode
Each user account is associated with a unique ClinSpark barcode. Application user barcodes can be printed from within the Action menu on user account administration screen.
User barcodes can assist in a number of workflows:
If a user scans their user barcode from the home page (Dashboard), the scan will automatically log them out.
If a user scans their user barcode from the login page, the scan will pre-fill their username for them and set the focus in the password box. Note: this functionality is only possible if the computer has been used previously for data collection.
If a user scans a ClinSpark user barcode within the context of form data collection, ClinSpark registers the input and performs the ‘Save and Close’ action on the form. The data is always attributed to the user who performed the scan and NOT the user badge that they scanned. Logic is in place to ensure that the right users are authorized to perform those ‘save and close’ actions.