Prompt for the username and password?

[madduck]

Prerequisites

• Tried the most recent nightly build
• Checked if your issue is already reported.

Is your feature request related to a problem?

A usability problem…

Describe the solution you'd like

I don't quite understand why the username has to be provided with X-Forwarded-User, but the web app then prompts for the password in client auth. Why can't it ask for the username there as well?

Describe alternatives you've considered

I could probably hack something up so that NGinX authenticates against the IMAP server to get the username, but that might mean that the user has to enter the password twice.

Right now, I am using this:

    location ~ ^/sieve/([^/]*)(.*) {
      proxy_pass https://managesieve$2;
      proxy_ssl_verify off;
      
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-User "$1";
    }

so that I can extract the user from the URL. However, this isn't ideal as it confuses the user.

[thsmi]

well, honestly this sounds like a very very special and rare use case.

I guess it needs a bit more detailed information on the rational why the web application normally does not need to have a username dialog.

Firstly the web application is based on the standalone application and the webextenions. Both don't need or have a username dialog in this scenario because it a mandatory setting when creating the account. This is why there is currently no such dialog prompting for the username. The classic add-on had such an option long time ago but it was never used because there was no use-case.

Concerning the web application, it is not so much different. You generally don't want to run in modern ages any kind of web application directly exposed to the outside world. Instead you use a reverse proxy which acts as your first line of defense and circuit breaker. All of the major reverse proxies I know are extremely hardened and zero day exploits are fixed extremely quick. Which makes them the perfect gate keeper. Only users authenticated against the proxy will pass and get access to the web applications. Which dramatically reduces the possible attack vectors. But this also means that the proxy knows for each authenticated user the username.

Thus it is quite common for modern application to outsource the complete authentication to a reverse proxy. This simplifies e.g. Singe Sign On and 2-Factor authentication extremely. Instead of implementing SSO and 2FA into each web application, you just offload this complexity to the reverse proxy. Means if a user tries to access the proxy without an SSO Cookie, then the proxy redirect the request to a nice SSO login dialog. You do there the two factor authentication and when completed it redirects you to original page. In case a user with a valid SSO Cookie accesses the proxy, it will add the authentication information for the web application silently to the request via a X-Headers.

What you use for authenticating your web applications depends on your reverse proxy configuration and your preferences. Basically everything is possible and highly depends on your SSO implementation you are using. The easiest but least secure way is to instruct the SSO Module to cache the credentials and add an X-Header with the username and one with the password. Another option is to configure your web application to do a "proxy authentication". Means you pass only the user information via an X-Header to your web application. In side your webapplication you use a special user which authenticates the forwarded user on behave. This is called proxy authentication, but requires that X-User information from the proxy is trustworthy. Which is normally not an issue on a back-end network. The by far most secure option is that the SSO module creates single use access tokens for each access and adds this via the X-Headers. But this needs extensive support from your Kerberos/LDAP or whatever backend is used. And everything in between is also possible.

So make a long story short, normally get with a reverse proxy SSO as well as 2FA for all your web applications with minimal effort. Thus you'll typically always go this extra mile, means you will always have the at least the username information on the reverse proxy. And this means you will be always able to do "proxy authentication" which does not require the user password.

I guess you can see, not having the user name available on your proxy and thus requiring a user name dialog is a very special and rare use-case.