Q1. What is the problem that we are trying to solve?
Currently, Passbolt provides two primary status flags for users:
active (indicating whether or not their setup is completed or pending)
deleted (indicating whether or not they have been removed from the system).
However, there is currently no functionality available to temporarily prevent a user from accessing the solution. This can create practical issues for administrators when a user goes on extended leave and does not require access temporarily, or when suspicious behaviour occurs and access needs to be removed until cleared.
It is worth noting that the “disabled” status option is present in other user directory solutions such as LDAP and Google user directory.
Q2 - Who is impacted?
The lack of a “disabled” status option in Passbolt primarily affects administrators who manage a large number of users or who rely on this feature in their LDAP.
Q3 - Why is it important and/or urgent?
The implementation of a “disabled” status option is important because it has been requested by larger organisations and its absence can hinder the adoption of Passbolt. This feature is crucial for organisations that need to quickly and temporarily revoke access for certain users due to extended leave, suspicious behaviour, or other reasons. Without this option, administrators are forced to delete or reactivate accounts, which can be time-consuming and inefficient. Therefore, the implementation of a “disabled” status option is urgent to meet the needs of organisations that use Passbolt.
Our proposed solution is to introduce a “disabled” field attached to the records in the users database table, allowing administrators to set this flag for a given user and mark them as enabled or disabled. Additionally, we propose allowing the user directory sync plugin to leverage this functionality and support it as a default setting for synchronizing the disabled status flag.
When a user is disabled, they will lose access to the solution, meaning they will not be able to perform certain operations such as:
authenticating using GpgAuth or GpgJwtAuth (mobile)
completing the MFA process
performing an account recovery
performing SSO operations
receiving any email notifications.
However, to allow users to rejoin the solution later, an active user will still be considered a valid target for sharing information. For example, if they are part of a group and a resource is being shared with the group, the user’s secret will need to be provided to complete the operation.
In order to provide visual feedback to other users, every user will be able to see if a given user is disabled. This will be shown as a visual indicator when they are adding them to sharing or group lists. Our proposed solution will give administrators the ability to quickly and temporarily revoke access for certain users, while still allowing them to rejoin the solution later and preventing the hindrance of adoption.
It sounds amazing, we would like to have it on the company I work for.
Is there an ETA for having this implemented? Just to inform the IT systems department
