When user is authenticated using external (REMOTE_USER) authentication, their attributes should get updated if the external environment provides the data

[Jan Pazdziora]

When external authentication is used, the traditional result is the username, passed to application via REMOTE_USER or similar mechanism.

With user identities being primarily managed outside of applications' user databases, user records in applications' databases (that need to be created so that foreign keys have parents) will increasingly be created during the first successful login. While the username might be enough for some applications, some might want the full set of attributes including the name and email address to get filled based on the data from the external identity/authentication source.

Since AbstractUser defines first_name, last_name, and email, I propose these attributes to be populated upon successful external authentication. The source of this data could be REMOTE_USER_FIRSTNAME, REMOTE_USER_LASTNAME, and REMOTE_USER_EMAIL based on the proposal at ​http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables.

With mod_auth_mellon 0.10.10 (for SAML), the configuration to populate these variables is

MellonSetEnvNoPrefix REMOTE_USER_FIRSTNAME givenname
MellonSetEnvNoPrefix REMOTE_USER_LASTNAME fullname
MellonSetEnvNoPrefix REMOTE_USER_EMAIL email

With mod_lookup_identity, the configuration would typically be

LookupUserAttr givenname REMOTE_USER_FIRSTNAME
LookupUserAttr sn REMOTE_USER_LASTNAME
LookupUserAttr mail REMOTE_USER_EMAIL

[Tim Graham]

I don't know what a patch would look like, but it seems like this request is tied closely to a particular project's requirements (for example, AbstractBaseUser doesn't have the fields you mentioned). Can it easily be implemented without touching Django itself? If not, I'd likely support adding a hook to make that possible.

[Aymeric Augustin]

I think this is getting into the territory of custom auth backend and middleware.

[Carl Meyer]

I agree. I think this is site-specific and Django already provides the necessary hooks to implement it. Contrib.auth does not need built-in support.

[Jan Pazdziora]

I'm sorry for not showing the patch right when I filed this ticket -- I got distracted by other things. I've now opened ​https://github.com/django/django/pull/5007 to show what I've envisioned as the solution for this ticket. Basically, new middleware which gets the REMOTE_USER_* headers and sets the fields in RemoteUserBackend. I've also included code which sets user membership to ext:-prefixed groups based on REMOTE_USER_GROUP_* headers.

Alternatively the code could be directly in RemoteUserMiddleware.

I'll fully understand if you don't like to include this code in the Django repository. But similar to https://code.djangoproject.com/ticket/25029 and the PersistentRemoteUserMiddleware that was added there, I feel that having the ability for Django projects to integrate without additional code into environments where user identities and authentication come from external sources could be benefitial for Django.

Flipping ticket back to new to bring it back to the radar.

[Tim Graham]

This doesn't seem sufficiently generic that it would be useful for many projects (we aim for 80% use case). Feel free to publish it as a third-party package or provide evidence that there's large demand for it.

[Jan Pazdziora]

Replying to timgraham:

Feel free to publish it as a third-party package or provide evidence that there's large demand for it.

Thank you for the review, appreciated.

[Jan Pazdziora]

For the record, django-identity-external in ​https://github.com/adelton/django-identity-external / ​https://pypi.python.org/pypi/django-identity-external implements this functionality in external middleware.