Selected OAuth Scopes: “Access your basic information (id, profile, email, address, phone)” and “Allow access to your unique identifier (openid)”.Īll 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”.Setup > Create > Apps > Connected Apps > New The Salesforce setup instructions are at Require claim organization_id:00Dxxxxxxxxxxxxxxx OIDCProviderTokenEndpointAuth client_secret_post There was some other subtle difference between registering the app in those two places, which I can’t remember off-hand.įinally, for Salesforce: OIDCProviderMetadataURL If you register at then it expires after two years.If you register the app on, the registration is valid to 2099.# However we do get It is possible that email will start to work soon:īeing Microsoft, they have two separate and incompatible ways of doing it: # Note: as at, the "email" claim doesn't work. 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. This requires creating a “consent screen”, followed by application type (Web application), with this authorised origin(s):Īfter which you’ll get the client ID and secret. To get the client ID and secret: in the Google API console create a new project, then create credentials for “OAuth client ID”. OIDCCryptoPassphrase XXXXXXXRANDOMXXXXXXX For passbolt, I just configured mod_auth_openidc on the Apache server where passbolt itself was running under mod_php.įor GSuite, add to the config (either globally or within a vhost): OIDCProviderMetadataURL I was mistaken when I said “reverse proxy”, I was thinking of a different application. We could publish it on the medium blog / help pages. That would be nice if you could document this setup. This means that non-company users cannot even see the passbolt server. (*) I have put passbolt behind a reverse proxy which uses mod_auth_openidc to validate the user has a company G-Suite account. 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. However, I note that deleted users are not actually removed from the database, they are just flagged as deleted. 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. 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 (*) 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. We have a user who forgot their passphrase
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |