Regenerating a user's key without changing E-mail address

1

We have a user who forgot their passphrase :frowning:

The FAQ says:

If you can’t remember your passphrase, the best thing to do is to start anew with a fresh key and ask for your team to share an existing password with you again.

That’s fine, but I’m not exactly sure of the mechanics of this, as I need the user to re-register with their existing E-mail address (*)

I think the process would be akin to deleting the user, getting them to re-register, and then adding them back to any groups they were in before. However, I note that deleted users are not actually removed from the database, they are just flagged as deleted.

What would you suggest as the best way to proceed? I am thinking I could delete the account in the GUI and then either delete the user fully via SQL, or change the E-mail address on the deleted account to a fake one.

Thanks, Brian.

(*) I have put passbolt behind a reverse proxy which uses mod_auth_openidc to validate the user has a company G-Suite account. This means that non-company users cannot even see the passbolt server.

2

@candlerb as far as I know it is possible to register a new user with the same email address than a deleted user (we even test in the testsuite that you can re-import the same previous key, in case they remember…). I’d suggest you try it first without out deleting the the previous user in SQL and let us know if you find any bugs.

3

That would be nice if you could document this setup. We could publish it on the medium blog / help pages.

4

as far as I know it is possible to register a new user with the same email address than a deleted user

It works - thank you! I forgot at first that I had to re-create the user within the GUI, in order to get their new invitation sent out.

(Plus I had to manually transfer ownership of some passwords, before I could delete the user - this has been discussed elsewhere)

5

That would be nice if you could document this setup. We could publish it on the medium blog / help pages.

Sure. I was mistaken when I said “reverse proxy”, I was thinking of a different application. For passbolt, I just configured mod_auth_openidc on the Apache server where passbolt itself was running under mod_php.

For GSuite, add to the config (either globally or within a vhost):

OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
OIDCClientID XXXXXX.apps.googleusercontent.com
OIDCClientSecret XXXXXXX

OIDCRedirectURI https://passbolt.example.com/oauth2callback
OIDCCryptoPassphrase XXXXXXXRANDOMXXXXXXX
OIDCScope "openid email"
OIDCSessionInactivityTimeout 3600

<Location />
   AuthType openid-connect
   Require claim hd:example.com
</Location>

To get the client ID and secret: in the Google API console https://console.developers.google.com/ create a new project, then create credentials for “OAuth client ID”. This requires creating a “consent screen”, followed by application type (Web application), with this authorised origin(s):

and redirect URI(s)

after which you’ll get the client ID and secret.

Something similar is possible with Office365: the config below is based on something I set up a year ago but is not recently tested by me.

OIDCProviderMetadataURL https://login.microsoftonline.com/<tenant-UUID>/v2.0/.well-known/openid-configuration

OIDCClientID XXXXXXXX
OIDCClientSecret XXXXXXXX

OIDCRedirectURI https://passbolt.example.com/redirect_uri
OIDCCryptoPassphrase XXXXXXXRANDOMXXXXXXX

OIDCCookiePath /
#OIDCSessionMaxDuration 28800
#OIDCSessionInactivityTimeout 300

OIDCResponseType id_token
OIDCResponseMode form_post
OIDCScope "openid email profile"

# Note: as at 21/10/2016, the "email" claim doesn't work.
# However we do get OIDC_CLAIM_preferred_username=user@example.com
# It is possible that email will start to work soon:
# https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-preview-oidc-changes/
<Location "/">
        AuthType openid-connect
        Require valid-user
</Location>

Being Microsoft, they have two separate and incompatible ways of doing it:

There was some other subtle difference between registering the app in those two places, which I can’t remember off-hand.

Finally, for Salesforce:

OIDCProviderMetadataURL https://eu1.salesforce.com/.well-known/openid-configuration

OIDCClientID <consumer-key>
OIDCClientSecret <consumer-secret>
OIDCCryptoPassphrase <any-long-random-string>

OIDCRedirectURI https://passbolt.example.com/redirect_uri
OIDCCookiePath /
OIDCSessionInactivityTimeout 3600

OIDCResponseType code
OIDCProviderTokenEndpointAuth client_secret_post
OIDCScope "openid email"

<Location "/">
        AuthType openid-connect
        Require claim organization_id:00Dxxxxxxxxxxxxxxx
</Location>

The Salesforce setup instructions are at Create a Connected App for ScreenSteps in Salesforce | Salesforce and ScreenSteps | ScreenSteps

Setup > Create > Apps > Connected Apps [lower down the page] > New

  • Connected App Name: [any name]
  • API Name: [name - spaces not allowed]
  • Contact Email: [your email]
  • Enable OAuth settings: [X] checked
  • Callback URL: https://passbolt.example.com/redirect_uri
  • Selected OAuth Scopes: “Access your basic information (id, profile, email, address, phone)” and “Allow access to your unique identifier (openid)”.
  • Start URL: https://passbolt.example.com/

All examples above are intended to limit you to just accounts within a particular domain: in GSuite and Salesforce explicitly by checking the “hd” or “organization_id” claims, and in Office365 implicitly by using a particular directory “tenant”. But I strongly suggest you verify for yourself that you’re not letting in other GMail / Office365 / Salesforce accounts.

1 Like