Up-to-date info regarding the rights model and functionalities of Passbolt?

Hi,

I’ve been trying (and failed) to find up-to-date, detailed but accessible info regarding the current rights model and functionalities (without SQL queries or the like, we consider the cloud version of Passbolt and have no ability to understand or implement that sort of things).

And in the details, I have some questions :

  • How does “ownership” of Passbolt account work ? Can we be at least 2 (or more) owners of the account, to avoid unilateral deletion by a rogue or careless employee ? When the/an owner quits the org, is there a way to transfer ownership ?

  • In past discussions prior 2020 or 2019, it was said that an admin cannot even know the existence of passwords not shared with him (at leasts those assigned to groups). Is there a role that can (1) know the existence of ; (2) access and manage, all passwords of all groups ?

This is really troubling that there is so little proper documentation on the app features. (see my recent query regarding the core features of Passbolt, that is… password sharing, which is - if I understand well - the core vision behind Passbolt !

Granted this is opensource, but since you propose paid SaaS on cloud, the documentation should in my opinion reach a minimal level of completeness and precision. It seems to me far from that at the moment.

Thanks in advance for your insights

Hello @xavrab ,

Thank you for your feedback.

A user account in Passbolt is linked to an email address and a private GPG key. To share an account with another user, you must share the private key of this account, and grant an access to the email address. So it is possible for example to setup an email for the shared email box of your IT department. Only administrators can create or delete users. There is no option to prevent a rogue administrator to delete a user at the moment.

Indeed there is currently no role or option who can know the existence and manage all passwords or groups of the organization. This is one of the design choice of passbolt. This allows people to store personal passwords in passbolt, or make sure the legal department passwords are not accessible by the IT department for example. As a workaround it is possible to train your users and make sure that you have a rule within your organization to share passwords with a “master account”. Unfortunately it is not something you can enforce via the administration settings at the moment.

However by the end of the year, we will provide a new functionality called account recovery, that will allow administrators to request a backup of the user private key (to help them in case they lose their passphrase, or access their password if they leave the org in bad term). You can learn more about the feature on our blog: What will the “Account Recovery” functionality look like?

We are aware of the lack of documentation on some parts of the product but we improve it every day. Feel free to make us a list of the documentation aspects you were looking for, we’ll make sure to add it to help the community as a whole.

As you are a passbolt customer, if you need more informations about Passbolt, you can also write us to support@passbolt.com. We would be be happy to schedule a demo meeting to answer your questions and get you up to speed with the current capabilities, best practices and the roadmap.

Best,

1 Like

Hi @AnatomicJC many thanks again for the detailed and prompt answer !

(actually, we are not yet Passbolt clients : precisely, I’m in charge of examining existing solutions to make a proposal so that we migrate to a password management app)

Regarding your answer related to the “ownership” : I am not sure that I understand correctly. Is it that there is no overall “organization’s ownership” as such ? Your reply deals with specific services, which are only sub-parts of the org. But, basically, there must be one (unique) Passbolt account for the organization, to which admins, group managers and users accounts are related ? no ? Do I miss something to the architecture of Passbolt ?

Regarding the lacking documentation : in my opinion, it should be top priority that you provide an up-to-date and complete doc on these two (somewhat related, obviously) points :

  • all features (present and, why not, also lacking) for sharing, groups, etc. with screen captures, as in your blog posts

  • a concise but complete and clear explanation of (all) the roles, covering the articulation between :
    the organization and the overall “ownership” of the org’s account > the admins > the groups managers > the users

Best

Hello, for all passbolt instances (CE, Pro, Cloud) you have a first admin that creates the organization (the same that install the software, or create the organization workspace on the cloud). From there they can invite other administrators and/or create regular users.

For the cloud (and pro), there is an additionally the concept of billing contacts. These contacts are not listed in passbolt UI, but in the billing and support systems. The first billing contact is created with the information you provided when you pay. These contacts can decide to change payment details, and/or the delete the organization workspace by contacting sales, or letting the subscription expires, etc. This is done by contacting the sales team.

Thank you for your feedback on the documentation, we’ll improve it in the next few weeks.
Best,

1 Like

Many thanks @remy for these precisions.

Hi @AnatomicJC

Previously you wrote :

I have begun our 14-day trial.
I created the org and thus I am admin.
I have created several users, and a group.
I have assigned a non-admin colleague as the group manager.
But I nonetheless can’t remove myself from the group.

It seems to me that it directly contradicts what you explained ?

The use case is that our Passbolt admins should not necessarily be able to access the accounting deparment passwords. So being an admin, once I have created the group, how can I remove myself ? can an admin be prevented from putting himself as any group’s member ?

How should I approach that ?

Hi :wave: ,

If you try to edit the group, and if your non-admin colleague is manager of this group, you are not able to remove yourself ?

After clicking on the cross, I am prompted to click on the save button

Then if I try to edit the group again, I’m not able to edit it anymore:

This doesn’t work for you ?

:pray: Ok, understood. I should have created the group while assigning myself as “group manager”, to then be able to remove myself. But I assigned myself as sole “member”. Anyway, I have seen that once my colleague was “group manager”, he could remove me, and then I couldn’t put myself back in the group. So it works as intended, fine !

Yes, it is mandatory for a group to have at least one “group manager”.

Some other points:

  • Only admin users can create groups of users
  • From the user menu, you can view all groups and their members
  • From the password menu, you can view only groups you are member of
  • a password can be shared with a group of users

There is 3 possible rights:

  • read: you can only access the password without modify it
  • update: You can update the password but you are also able to delete it (:warning: Danger zone :warning: )!!!
  • owner: the only difference with the update right is the ability to share the password

A improvement of the users/groups ACL is in our backlog. We have well received your support request and will contact you shortly to organize a meeting to answer to your questions.

Best regards,

1 Like

@xavrab

Hello there!

We use Passbolt at my company and I think I have solution for one of your problems - master account sharing.

We have 2 Passbolt servers (for High Availability) and each of them has an accessible RDP console. You can log in with a shared admin account, which has the “master account” profile in it’s browser and from which everything is managed. I think this is the ideal solution to this problem and has been working for us rather well.

I’d be happy to provide assistance on how to set something like this up!

Best regards,
Jakub

Hi @jkubik , thanks for sharing your experience !

I’m sorry but I don’t clearly understand the architecture you put in place. At the very least because I don’t understand at all what this sentence means : “We have 2 Passbolt (for HA) and each of them has an accessible RDP console.” Not understanding that one, I am very unsure I understand correctly what’s next.

Please could you provide more details ? (please in non-technical language, as far as is possible / relevant ; I am not at all sysadmin or whatever, just a communication officer with some geeky orientation, in charge of the password management question, since we have no IT department or colleague…)

Best regards,

Xavier

I apologize, the word “servers” has slipped out of my message (I have edited the message to be easier to understand somewhat).

What I meant is that I have a standalone administrator account, with its own private and public key, which is only accessible from those 2 Passbolt servers using a browser after connecting to them through Remote Desktop.

I will also add that there more differences between “update” and “owner”, such as the ability to add or remove tags.

I do think this should be present in the “update” role, but that is a topic for another thread.

Hi,

For your information, we published some new documentation about rights model and functionalities of passbolt:

Best,