SSO integrated auto-provision with provisioning of new accounts

Feature requests
1

Hello. We’re evaluating Passbolt Pro for a 50-100 person userbase.

We’re running ‘on prem’ and using SSO via Keycloak (bouncing off an Active Directory and/or Linux Kerberos+LDAP).

We’re quite happy with the Keycloak mode of operation for intranet sites (although the blog post on configuring it is a little out of date).

What we’re finding painful though is the provisioning of new users - setting up passbolt access on Firefox + Chrome on Linux + Firefox.

Syncing users to AD or LDAP seems satisfactory, but ultimately we can just handle that via an API-script.

What’s painful is the need to ‘recovery’ the user’s private key and passphrase 4 times to ‘set them up’. Even with the saved ‘recovery kit’ - and the more useful ‘administrator can approve recovery’ in pro mode, it’s still not a smooth process to install the plugin, add the user’s credentials and get them ‘set up’ in a way that will be smooth on an ongoing basis.

So the feature I’d like to suggest is that ‘user recovery kits’ are effectively disabled, and managed via the central service, and there’s some sort of option to just trust the SSO to be telling the truth about who someone is, and set them up automatically.

We are quite happy that distributing ‘automatic’ recovery packages/scripts within our enterprise/over ssl is ‘sufficient’ security, and would instead be looking at scripting the whole process of ‘create account, extract recovery kit, set passphrase and then re-import for each browser instance and environment’.

e.g. maybe a pfx file that could be imported into the browser automatically along with the plugin installation? (And could be ‘fetched’ via SSO-authenticated download to a distribution service).

Otherwise we’re just not going to be able to use this - users ‘self managing’ encryption keys will for sure lead to a worse exposure and/or repeated forgotten passphrases and lost keys.

My ideal would be that the SSO integration ‘reads’ the username-claim token passed from the SSO provider, and creates an account if that exists, or downloads a ‘package’ for the plugin to use if that doesn’t exist, before forwarding the user to the ‘normal’ login.

1 Like
2

If the server itself is directly distributing both the encryption key and the passphrase (or the encryption key in cleartext), then the trust boundary is effectively broken. This is why Passbolt’s current design pushes for users to remain in control of their keys. If we moved key generation and distribution fully to the server, it would no longer provide the same security guarantees.

However this could be moved to a separate service, for organizations that have the same risk apetite than yours for example. What I would personally lean toward is building an agent (e.g. a script or lightweight service) that acts as a Passbolt administrator who’s goal is to “provision clients”. This agent would have access to the account recovery key.

The agent would:

  • Authenticate with its own technical account.
  • Generate the key pair on behalf of the user
  • Complete the setup on the user behalf registering the new key
  • Place the user key in escrow with account recovery feature

From there:

  • User performs starts the account recovery procedure as their “signup experience” using SSO.
  • The agent help the user completes the account recovery request (an additional check could be set here, for example requiring an approval from another admin, etc.)
  • The user get a hold of their kit and completes the account recovery

I think this is reaches your goals while conserving the trust boundaries. Obviously if that agent is compromised, all bets are off.

2 Likes
3

Ultimately I care less about the trust boundary than I do with making this product accessible.

We have users with a wide range of technical awareness - some of which feel that password sharing by email is a reasonable solution to a problem.

If we want to mandate using a password manager, we need to enable it in a way that means it’s also the easiest way to share credentials.

This in turn means we need to be able to automate the setup for people who don’t have inclination or patience to do any ‘maintenance’ like managing keys. Because they won’t, they’ll keep doing the ‘easy’ thing.

‘breaching the trust boundary’ by having an admin extract the keys/set passphrases/autologin etc. is IMO worse than mandatory key escrow and auto-configuration/download.

4

I think we agree the on-boarding needs to be simpler, I was just explaining the product design constraints. I think we both agree that if end to end encryption is just for show, then one might as well just use a spreadsheet (as in one will have access control and encryption in transit, but not more).

1 Like