How to setup django-auth-ldap for SSO?


I didn’t find any Python/Django project that worked with SSO.

It seems that GitHub - django-auth-ldap/django-auth-ldap: Django authentication backend that authenticates against an LDAP service. is the best choice to support SSO.

But i don’t know how to setup it correctly. Any ideas?

EDIT: I just started here: Support SSO authentication by jedie · Pull Request #11 · YunoHost-Apps/pyinventory_ynh · GitHub

1 Like

You forgot a couple of parameters actually. I am still failing to log in, but the messages are a bit more helpful. Can I push to your testing branch?

I’m done: It worked :wink: The “testing” branch already merged.

1 Like

Oh great! I see that you removed the groups permissions, that’s what I was blocking on.

I don’t know if everything is really working. But for now, i can login as superuser that is created on install.

Think a new user, will not work, because of missing setup a new user correctly.

Maybe will also setup new users as “normal PyInventory” users…

Why not using the Groups and permissions? (more info here too)

1 Like

Thanks for the link.

Yes, i should see if i can map the Yunohost “admin” user to the Django superuser… But for now, i’m fine with current solution made in :

  • first user is superuser
  • all other users are normal users in PyInventory

But i will add it to the TODO ->

1 Like

See this part of file

Hm. If i see it correct: all sftpusers users will be a superusers, isn’t it?

Yes, but this package is a bit old, the correct way today is to create several permissions and to refer it. Something like that:

ynh_permission_create --permission "main" --url /
ynh_permission_create --permission "staff" --url /admin/
ynh_permission_create --permission "admin" --url /admin/

And in ldap conf:

    "is_active": "cn=main.APP,ou=permissions,dc=yunohost,dc=org",
    "is_staff": "cn=staff.APP,ou=permissions,dc=yunohost,dc=org",
    "is_superuser": "cn=admin.APP,ou=permissions,dc=yunohost,dc=org"

J’ai pas testé donc je suis pas sûr à 100%, mais c’est l’idée.


Thanks for your work. I was actually going to start tackling to package benevalibre.

For now, if I understand well, you don’t fetch the user via nginx, but via another login—plugged into the LDAP, right?

1 Like

There are 2 ways to connect with a yunohost account:

  • through LDAP request
  • with the REMOTE_USER HTTP header (given by ssowat)

Here i show the LDAP method, with a django module plugin, cause the question was django-auth-ldap.

Here you can find documentation for the second method .This second method allows to autoconnect a user already connected to the YunoHost User Portal (SSOwat).

It works for django, for other apps, you need to find if the app support it (natively or with a module).

1 Like

think i will look at this. Because then the user can be quickly logged in, if i understand this right…

Maybe a combination is nice :wink:

Can i just trust this header? How to verify it?

Yes you can just trust this header if sso is not configured with a skipped_uris (so if it’s protected or unportected it’s ok). The header “Remote-User” is added by SSOwat with the login of the user logged.

In this second link, we see it’s possible to get Name and email too.

Searching in code this info, i see the basic auth is also supported. But i don’t know how to use it exactly. It seems the login:password popup is prefilled with the basic auth mechanism of nginx (or a reverse proxy app?)…

Hm. Is there any django app that used this already? I didn’t find something like this…

I’m experimenting here:

I don’t known whats the best practice here, because of the warning in Django docu:

It seems, this warning doesn’t apply for Remote-User header. And i made some test with nextcloud app, and it was not possible to login by adding itself the remote user header

I debug a little bit and looked into the sent headers. I add this in nginx:

proxy_set_header REMOTE_USER $remote_user;

I get this:

'HTTP_REMOTE_USER': 'foo,foo'

This is nothing that will work in default RemoteUserMiddleware implementation…

Ah! Strange:

With proxy_set_header X-Remote-User $remote_user; i get this:

'HTTP_AUTH_USER': 'foo',

I get the same values with: proxy_set_header X-Auth-User $remote_user;

With proxy_set_header REMOTE_USER $remote_user; this:

'HTTP_AUTH_USER': 'foo',
'HTTP_REMOTE_USER': 'foo,foo',

And with proxy_set_header OWN_HEADER $remote_user; this:

'HTTP_AUTH_USER': 'foo',

And at least proxy_set_header X-WEBAUTH-USER $remote_user;:

'HTTP_AUTH_USER': 'foo',

So, what’s the best choice here?!? Maybe X-Remote-User ?