As a user / admin I would like to be able to login via Azure AD

#1

Q1. What is the problem that you are trying to solve?
We use Office 365, Azure and the od app that supports Azure AD. It would be nice to be able to allow authentication via Azure AD / Office 365 for passbolt

Q2 - Who is impacted?
Our users who need to log in, our administrators who manage our users.

Q3 - Why is it important and/or urgent?
Just nice to have, one less password to manage :smile:

Q4 - What is your proposed solution? (optional)
I have built apps that do this, normally via JWT, I am sure the dev team know how this would work.

0 Likes

#2

Hello @SteveDrakey ,

Currently passbolt pro supports users and groups synchronization using active directory / openldap. It shouldnt be too hard to make it work for Azure AD if it’s not already working (I haven’t tested it).

Concerning authentication using AD it is not a trivial problem and was discussed before. The way authentication works in passbolt is by using a protocol called GpgAuth. It is a challenge based authentication, not a password (or token based auth). The passphrase in passbolt is used to decrypt the private key, so it cannot be easily tied to directory credentials (mostly because of when the directory password changes).

One approach would be to store the passphrase to decrypt the private key in the directory, but this is not considered a very secure approach and would require schema customization in active directory, which is not very practical.

Feel free to share your thoughts on that topic in this thread.

0 Likes

#3

thanks for the reply, maybe just have a way to import users via AzureAD, the user would then need to login via AzureAD to allow them to use Passbolt. I guess this skips the email verification step.

Or, for a tighter integration something like

First time login process :

  • User navigates to Passbolt
  • Azure AD Auth takes over, normally the user would not need to enter their username or password, it should just work… Ofc any 2FA would kick in etc.
  • Passbolt knows who they are, the JWT token has been generated with this info.
  • Passbolt has not seen this user before, so it asked the user to create a passphrase
  • Works as normal

Next time

  • User navigates to Passbolt
  • Azure AD Auth takes over, normally the user would not need to enter their username or password, it should just work… Ofc any 2FA would kick in etc.
  • Passbolt knows who they are, the JWT token has been generated with this info.
  • Passbolt has seen this user, it needs to know the passphrase so it asks the user for this (ofc, this could be set to remember etc)
  • Works as normal

To add a little extra layer of security, you could use the passphrase with part of the jwt token, maybe the oid value. This would mean if the user has been deleted or disabled in AzureAD they would not be allowed to access customer passwords.

0 Likes

#4

@SteveDrakey thank you for the detailed process explanation. I believe what you describe should already be possible actually using a reverse proxy in front of passbolt with a tool such as https://github.com/bitly/oauth2_proxy spinoffs:

  • pomerium an identity-access proxy, inspired by BeyondCorp.
  • buzzfeed/sso a “double OAuth2” flow, where sso-auth is the OAuth2 provider for sso-proxy and Google is the OAuth2 provider for sso-auth.
  • openshift/oauth_proxy an openshift specific version of this project.
  • pusher/oauth2_proxy official hard fork of this project.
0 Likes