[Nav-users] Re: REMOTE_USER / Shibboleth SSO login silently fails to pass forward parameters right

27 Aug 2026

      Hi,
We have made a little fix for the problem.

Now another little finding. This will probably be a small fix, but it creates some problems among users.

False "insecure/plaintext password" warning for newly created remote user accounts:

After fixing the login issue, newly created (authenticated) REMOTE_USER accounts see a banner: "Your account has an insecure or old password. It should be reset." The same false positive also appears in the "User and API Administration" tool: "This account's password is stored in plain text. Its password should be changed immediately, or the account disabled."
Attempting to act on either warning leads to the change-password page, which correctly refuses:
"You are not allowed to change your password from this page. Your account is managed through an external system, known as 'REMOTE_USER'." — i.e. two parts of the UI give contradictory guidance for the same account.

The problem probably is that the REMOTE_USER accounts are now in 5.1 9created via Django.
In the database, for the accounts created, the password column is left as an empty string, not a secret. (We see old remote accounts, created with NAV (not Diango) have a dummy secret.

You see:

        login         |                             password                              | pw_len |  ext_sync
     ...
     user-old-by-nav@xyz      | {pbkdf2}xxxxxxxxxxxxxxxxxxxxxxxx |     65 | REMOTE_USER
     ...
     user-new-by-diango@xyz   |                                                                   |      0 |  REMOTE_USER

It seems that, some check fails for an empty string, and it is reported as "plaintext" instead of something else: no local password or externally managed password or similar.

To correct the check may probably be a simple fix, hopefully.

  Med vänliga hälsningar
  Kejvan

________________________________
From: Kejvan Redjamand <kejvan@chalmers.se>
Sent: Friday, August 21, 2026 12:52
To: nav-users@lister.sikt.no <nav-users@lister.sikt.no>
Subject: [Nav-users] Re: REMOTE_USER / Shibboleth SSO login silently fails to pass forward parameters right

This is the Environment.
May be the code is corrected elsewhere but not I Debian's distribution?

| Component            | Version                                   |
|-----------------------|--------------------------------------------|
| NAV                   | 5.19.0                                     |
| Python                | 3.13.5                                     |
| Django                | 5.2.15                                     |
| django-allauth        | 65.18.0                                    |
| django-htmx           | 1.27.0                                     |
| django-filter         | 25.2                                       |
| django-tagging        | 0.5.0                                      |
| djangorestframework   | 3.17.1                                     |
| PostgreSQL            | 17.11 (Debian 17.11-0+deb13u1)             |
| libapache2-mod-wsgi-py3 | 5.0.2-1                                  |
| Shibboleth SP         | 3.5.0                                      |
| OS                    | Debian 13.6 (trixie)                       |
| NAV install method    | Debian package into venv (`/opt/venvs/nav`)|

Kind Regards,

Kejvan

________________________________
From: Kejvan Redjamand <kejvan.redjamand@chalmers.se>
Sent: Friday, August 21, 2026 12:44
To: nav-users@lister.sikt.no <nav-users@lister.sikt.no>
Subject: REMOTE_USER / Shibboleth SSO login silently fails to pass forward parameters right

Hi,

We have a problem in authentication with shibboleth (SSO) and nav, which we would like to know if there is any resolution for.
The authenticated user is  seen in Apache variables but not passed to nav.
This is not a Shibboleth, Apache, or `webfront.conf` configuration problem.
It is a code defect probably introduced in 5.17.0 and probably still present, unchanged, in
5.19.0 (latest at time of writing).
It might be a known bug (resolved?) but still present.

It seems to be some shortcomings in the code in
file (`/opt/venvs/nav/lib/python3.13/site-packages/nav/web/auth/backends.py`)
...
import logging
from django.contrib.auth.backends import RemoteUserBackend
from nav.auditlog.models import LogEntry
from nav.web.auth import remote_user
_logger = logging.getLogger(__name__)
class NAVRemoteUserBackend(RemoteUserBackend):
    "An adaptation of Django's RemoteUserBackend that is configurable the NAV way"
    def __init__(self):
        self.create_unknown_user = remote_user.CONFIG.will_autocreate_user()
    def authenticate(self, request, user):
        if not remote_user.CONFIG.is_remote_user_enabled():
            return None
        user = super().authenticate(request, user)
        return user

With DEBUG logging enabled for `nav.web.auth, we see that web-server side is fully functional.
...
request.META["REMOTE_USER"]: "user@xxx.yyy"
[INFO] nav.web.auth.signals] failed login: None
REMOTE_USER: "default" from "/navlets/get-user-navlet/12?mode=VIEW"
...

`REMOTE_USER` is present and correct in `request.META`, confirming the
web-server side is fully functional. The subsequent `failed login: None`
and fallback to the `default` (anonymous) account confirm the failure
occurs entirely inside NAV's Django authentication backend dispatch.

Auto creating accounts does not work, since the remote_user is not passed along right.

## Steps to reproduce

1. Deploy NAV 5.19.0 behind Apache + Shibboleth SP, with
   `webfront.conf`:
...
   [remote-user]
   enabled = yes
   varname = REMOTE_USER
   autocreate = yes

2. Log in via the IdP. Shibboleth authenticates successfully and Apache
   passes `REMOTE_USER` correctly (verified independently via
   `LogFormat "... REMOTE_USER=%u" ...` / `%{REMOTE_USER}e` in Apache access
   logs — confirms the header reaches Apache/mod_wsgi).
3. NAV does not log the user in; the session remains bound to the
   anonymous/`default` account.

Is there any suggested solution?

Kejvan Redjamand

www.chalmers.se<http://www.chalmers.se/>