[Django] #25042: When user is authenticated using external (REMOTE_USER) authentication, their attributes should get updated if the external environment provides the data
Django
their attributes should get updated if the external environment provides
the data
-------------------------------+--------------------
Reporter: adelton | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25042>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* type: Uncategorized => New feature
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:1>
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I think this is getting into the territory of custom auth backend and
middleware.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:2>
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by carljm):
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:3>
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by adelton):
* status: closed => new
* resolution: wontfix =>
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:4>
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:5>
Django
their attributes should get updated if the external environment provides
the data
Reporter: adelton | Owner: nobody
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by adelton):
Replying to [comment:5 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:6>
Django
their attributes should get updated if the external environment provides
the data
Reporter: Jan Pazdziora | Owner: nobody
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25042#comment:7>