#689: using REMOTE_USER
koenb
(thanks Joseph Kocherhans).
It combines the use of a middleware and an authentication backend to
use the Remote_user information passed down by apache. This is usefull
in intranets where you can use apache with mod_ntlm or mod_auth_sspi
to authenticate the user in the intranets domain.
It is a very simple version: any unknown user is considered to be
valid (apache authenticated) and is simply added to the user database
without extra info. It is easy to do extra stuff by subclassing the
backend. I can think of eg getting the users email-adres and maybe
setting custom permissions via LDAP.
I am not sure whether the backend should do more by default than it
does now. My guess is it would be better to extend the documentation
with some more complex examples.
Koen
Ramiro Morales
>
> I added a new patch to ticket 689. This one does not use settings
> (thanks Joseph Kocherhans).
> It combines the use of a middleware and an authentication backend to
> use the Remote_user information passed down by apache. This is usefull
> in intranets where you can use apache with mod_ntlm or mod_auth_sspi
> to authenticate the user in the intranets domain.
> It is a very simple version: any unknown user is considered to be
> valid (apache authenticated) and is simply added to the user database
> without extra info. It is easy to do extra stuff by subclassing the
> backend. I can think of eg getting the users email-adres and maybe
> setting custom permissions via LDAP.
I've been slow in assembling the the pieces of a setup here at work
(Windows domain) using Windows + Apache 2.2 + mod_auth_sspi +
mod_wsgi + Django trunk) to test this patch as I promised on #django
during the sprint (I'm cramm on Freenode) but I hope to be able
to post some feedback RSN.
Also I've made some updates/fixes to the docs/auth_remote_user.txt
file added by Koen's patch and will be attaching an updated one
to the ticket.
There is an additional design level detail regarding the interface implemented
by Koen's last iteration of the patch and that's the reason I'm sending this
message to the list:
It is related to how an authentication backend implementing such and
interface would be affected by the changes implemented on [1]r6375
("Fixed #5457 - the auth system now delegates permission checking to
auth backend(s). As an added bonus, the auth backends now have some
unit tests! Thanks, Florian Apolloner."). In other words, should
RemoteUserAuthBackend:
a) simply inherit the four new authorization methods::
get_group_permissions(self, user_obj)
get_all_permissions(self, user_obj)
has_perm(self, user_obj, perm)
has_module_perms(self, user_obj, app_label)
from the ModelBackend class deferring to it's custom authenticator
subclasses the decision to break reliance on the django.contrib.auth app
('auth_permission' and 'auth_group_permissions' tables)?
b) Or should it implement empty versions of these methods
imposing it's subclasses a decoupling from the auth app?.
c) Another possibility I didn't take in account?
What do you guys think?.
Regards,
--
Ramiro Morales