Opened 5 years ago

Closed 5 years ago

#25029 closed New feature (fixed)

When external authentication via REMOTE_USER is only configured on /admin/login/, the authentication does not persist

Reported by: Jan Pazdziora Owned by: nobody
Component: contrib.auth Version: master
Severity: Normal Keywords:
Cc: Jan Pazdziora Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The ticket #17869 made sure that if the REMOTE_USER header is not present, user is logged out in Django as well. Ticket #23066 moved the logic to different method but the semantic stayed the same.

However, for certain external authentication mechanisms, it makes sense that the frontend server (Apache) is configured to only authenticate single URL, like /admin/login/. For example with Kerberos, we do not want the negotiate to happen upon every request -- we want Django to accept the external authentication, create the session, and then use that session until the user explicitly log out.

I assume changing the current behaviour of RemoteUserMiddleware is not acceptable so I'm proposing new middleware, OptionalRemoteUserMiddleware, to allow the REMOTE_USER to be only present once.

Change History (10)

comment:1 Changed 5 years ago by Jan Pazdziora

Cc: Jan Pazdziora added
Has patch: set

comment:2 Changed 5 years ago by Carl Meyer

Is there any compelling benefit to having this in core Django rather than an external library?

I'm not convinced the need is frequent enough to have it in core Django. (Even RemoteUserMiddleware itself is on the edge, IMO).

comment:3 in reply to:  2 Changed 5 years ago by Jan Pazdziora

Replying to carljm:

Is there any compelling benefit to having this in core Django rather than an external library?

The benefit is increased number of deployments of existing applications that can be done by changing one line in MIDDLEWARE_CLASSES in settings.py. In many cases the person deploying that application which needs to consume external authentication is not a programmer and dealing with extra code is a blocker. Having the option come directly with Django seems more straightforward. From maintenance point of view, the class touches some internals of Django that it seems best to have it with the rest of the RemoteUserMiddleware code so that should the internals change, people are not faced with the task of getting correct version of the external library.

Normally I'd say that RemoteUserMiddleware should not even insist on seeing the REMOTE_USER filled upon every request but I guess changing the current behaviour might be disruptive, that's why I'm proposing a way for admin to be explicit with their choice of behaviour.

The traditional model of REMOTE_USER being produced primarily by setups with HTTP Basic Auth which keeps sending the credentials with every request and thus the username available with every request is no longer there as virtually noone uses Basic Authentication, while external authentication in frontend HTTP server can bring benefits especially in large organizations when the Apache modules are used for cross-realm authentication or identity federation. The typical use-case is then to override or extend one (logon) URL. We have a writeup about the approach at http://www.freeipa.org/page/Web_App_Authentication.

Another benefit for Django as a project is that it would make it much easier to use Django in demos of external authentications, be it Kerberos, SAML, or other.

I'm not convinced the need is frequent enough to have it in core Django. (Even RemoteUserMiddleware itself is on the edge, IMO).

It's not in core Django, it's in django/contrib/auth. I thought the contrib in the name makes it a good place to live, especially for "integration" code like this.

You might not see many RemoteUserMiddleware deployments exactly for the reason that with other authentication mechanisms than Basic Auth, it's currently not particularly useful.

comment:4 Changed 5 years ago by Carl Meyer

Ok, I'm convinced that this new variant is at least as useful as RemoteUserMiddleware itself. I won't stand in the way. Thanks for the expanded rationale.

comment:5 Changed 5 years ago by Aymeric Augustin

See #17869 for the opposite request.

comment:6 Changed 5 years ago by Jan Pazdziora

I've updated the pull request to use the class name PersistentRemoteUserMiddleware as proposed during the review.

comment:7 Changed 5 years ago by Claude Paroz

Needs documentation: set
Needs tests: set
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature

comment:8 Changed 5 years ago by Jan Pazdziora

I've now added commits with basic test and amended remote user authentication document to the pull request.

comment:9 Changed 5 years ago by Jan Pazdziora

Needs documentation: unset
Needs tests: unset

New squashed and rebased commit 83de95a1b777890e710dc2fa867dc8a36eb34c71 has tests and documentation fixes.

comment:10 Changed 5 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In a570701:

Fixed #25029 -- Added PersistentRemoteUserMiddleware for login-page-only external authentication.

Note: See TracTickets for help on using tickets.
Back to Top