LDAP authentication


#1

Hi.

I opened a new thread regarding LDAP authentication, continuing the discussion from here.
I haven't managed to get it working yet but I'm still trying.
If anyone manages to get it working please reply :)


#2

Thanks! Let me know how you work out with things and if you hit any specific errors.

I have NOT had much experience with LDAP in the past though that shouldn't require any specific Vespene code changes.

Possible exception - I suspect you will want to leave both the LDAP model and the database model enabled at the same time OR use the authz features to disable user/group creation in the UI. We can definitely consider a way to remove those features from the admin views.


#3

Hi. I've got it working!
I will also work on adding groups but I must find out more about how LDAP is configured first.
The django-auth-ldap settings from the documentation example are pretty straightforward. I used that example and after finding the correct parameters for LDAP, it works. I put the file in /etc/vespene/settings.d/ldap_auth.py.
I left the ldap as the only authentication backend for now, and will try to look into disabling user/group creation.
Thanks!


#4

AWESOME!

Users and Groups in Vespene at the moment do allow the superuser to bypass the AuthZ checks here:

http://docs.vespene.io/authz.html#groups-required

So what I think we'll need is just a configuration setting that disables them in the navigation and ideally ALSO just hard-disables the routes that allow them to be saved as well, if set.

Assuming you like writing Python code and want to take a look, I'd say this wouldn't be a hard pull request at all. If not, I can add it to my list.

I am thinking it could be like "ALLOW_UI_USER_CREATION" and "ALLOW_UI_GROUP_CREATION" as boolean settings, defaulting them to True in config/core.py

And then the views would just have to know what to do with that.


#5

I added the settings in core.py and added an if in jinja2/theme.j2 to try and remove the buttons. It removed the buttons but doesn't bring them back when the settings are 'True'. Is this the wrong approach?

{% if ALLOW_UI_USER_CREATION is sameas true %}
<li><a class="{% if object_label == 'User' %}active{% endif %}" href="/ui/users">Users</a></li>
{% endif %}
{% if ALLOW_UI_GROUP_CREATION is sameas true %}
<li><a class="{% if object_label == 'Group' %}active{% endif %}" href="/ui/groups">Groups</a></li>
{% endif %}

I did a similar if for the routes and that seems to work.

if settings.ALLOW_UI_GROUP_CREATION:
urlpatterns.extend([
    path('ui/groups', GroupView.list, name='group_list'),
    ...

#6

I've not seen the Jinja2 "is sameas" before (honestly a lot of Jinja2 is weird!), but IMHO I would just write that as:

{% if ALLOW_UI_USER_CREATION %}

To make this more easy, it might be easiest to expose Django settings directly to the template context, rather than individually injecting all those parameters into the Jinja2 environment.

So

{% if settings.ALLOW_UI_USER_CREATION %}

As for the restart issue, I'm guessing that would pick up when you restart the service.

My preference for the routes code would be to issue a 403 Forbidden from inside the group list method instead, which could be done by editing GroupView.py - this way the route is consistently present across installations but still works as expected.


#7

This is great btw - If you want to polish that up and send me a pull request, I'll take it. Also if you want to send me any notes on LDAP setup, I can see about starting a page about LDAP configuration on the main doc site.


#8

Hey quick reply on the settings suggestion I made - this is a bad idea, because it allows access to sensitive variables in the template engine

I would pass into the context a small dictionary of just the settings you need, maybe name it like "limited_settings.