Additional Cloud Identity Providers for Login

[RRohi]

🚀 Feature Request

Allow configuration of identity sources from cloud identity providers, such as Azure Active Directory (AAD) and the like.

🔈 Motivation

PasswordPusher currently has a login feature, that largely functions as we need it to, but the users are local, which is not great. We would rather take users from AAD, using groups.

I've set up PasswordPusher in Azure, using the following guide: #277 (comment)
I configured authentication on the app level, but the problem here is that the one who receives the password would also have to authenticate and that is not how we want it to work.

We want our users to authenticate, via our cloud directory, to use the service, and the password receivers to access the page anonymously.

🛰 Alternatives

📎 Additional context

[pglombardo]

Hi @RRohi - I agree. I've had this on the list for quite a while.

One item of note:

the password receivers to access the page anonymously

This should be the case now. For Password pushes, to receive through a secret URL, no login is required. Did you possibly add custom authentication?

On everything else I'm in agreement. Hopefully I can get to this sooner than later.

[RRohi]

This should be the case now. For Password pushes, to receive through a secret URL, no login is required. Did you possibly add custom authentication?

The issue with the current implementation is, for us, that
1: no authentication (default) - everyone can access the password-sharing page. We want it to be gated for internal users.
2: internal authentication solution - users are local and over time difficult to manage. Other than that, it works as it should.

In the last sentence, I summarized how we would like it to end up working, as a whole, which is why I added the anonymous bit, although it already works.

So, the focus is still on being able to use external authentication providers.

[Viajaz]

This is mostly a duplicate of #410

[Viajaz]

@RRohi consider using a reverse proxy and splitting the password generation portal and password viewing functionality onto different domains and protect the first with an Azure Application Proxy. That's what we have been doing in testing. Let me know if you're interested in NGINX configuration on how to do this.

[clahil-linum]

@Viajaz I would like to see the nginx configuration please.

[pglombardo]

If you need it, there is a generic nginx example here: https://github.com/pglombardo/PasswordPusher/tree/master/containers/examples/pwpush-and-nginx

[burak40]

@RRohi consider using a reverse proxy and splitting the password generation portal and password viewing functionality onto different domains and protect the first with an Azure Application Proxy. That's what we have been doing in testing. Let me know if you're interested in NGINX configuration on how to do this.

@Viajaz , is this also achievable in Azure ? I'm running now the application in Azure with APP service plan + Web + docker. Could you please give more info about splitting?

[Viajaz]

@clahil-linum @burak40
This is an example NGINX configuration, I've not tested the below. It doesn't have logging, proper error pages, thorough support for branding, access control or other good practice security features, it just shows how you can split out three parts of PasswordPusher into three server blocks using NGINX as a reverse-proxy. You could adapt this idea for other reverse proxying software, I'm sure.

• pwpush.example.com is intended to be the admin interface, essentially, allows for full access.
• password.example.com is intended to be the public interface that allows viewing of password, you would have to amend it for the new files and URL features.
• pwpush-api.example.com is intended to be for API for password use only, you would have to amend it for the new files and URL features.

upstream docker-pwpush {
  server 127.0.0.1:3000;
}

server {
  listen 443 ssl;
  server_name pwpush.example.com;

  include /etc/nginx/snippets/ssl.conf;

  location / {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://docker-pwpush;
  }
}

server {
  listen 443 ssl;
  server_name password.example.com;

  include /etc/nginx/snippets/ssl.conf;
  
  location /assets/ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $host;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://docker-pwpush;
  }
  
  location ~ ^\/branding\/([0-9a-zA-Z\-_]+?\.[a-z]+)$ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $host;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://docker-pwpush;
  }

  location ~ ^\/[a-z]+\/p\/[0-9a-zA-Z_-]+(\/[0-9a-zA-Z]+)?$ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://docker-pwpush;
  }
}

server {
  listen 443 ssl;
  server_name pwpush-api.example.com;

  include /etc/nginx/snippets/ssl.conf;

  location ~ ^\/(api|p(\/.+)?\.json)$ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://docker-pwpush;
  }
}

[pglombardo]

I'm investigating expanding the authentication system and re-reading some of this feedback. Hopefully I'll have something tangible soon.

I did notice one point re: @RRohi

1: no authentication (default) - everyone can access the password-sharing page. We want it to be gated for internal users.

As a temporary bandaid you can set the environment variable PWP__ALLOW_ANONYMOUS=false which "When false, requires a login for the front page (to push new passwords)."

If it might help, documentation is here.

[pglombardo]

Two updates for this issue:

1. SSO is live on pwpush.com and coming to the OSS version soon
2. We now have a public gateway container that is a "cut down version of the pglombardo/pwpush container, designed to be hosted publicly and only deliver pushes to end users"

Once SSO is in the OSS code base, you should be able to create a client app, add credentials and limit who can access the application.

The two feature requests for SSO & OpenID are #1609 & #410.

I'll update those two issue when everything is out in the OSS version.

If nothing remains here, I'll close out this issue soon. Let me know if otherwise!