Proposal: LDAP/AD auth on controller

[phspagiari]

As we discussed at #1578, in order to use deis at large companies we need a way to use LDAP authentications on deis.

I would be happy if I start to contribute with deis using this idea, indeed I already tested some ideas, but it will be very good if some of the core developers help me with the design of the idea making easy to use and administer.

So far I learned about how integrate ldap with django and already tested with a simple authentication app in django, so far so good.
Now I want to implement this on the controller and extend the configuration to etcd + deis client since the ldap configs are located in settings.py of the controller.

My idea is something like this:

• django-auth-ldap, ldap and python-etcd as requirements of deis-controller.
• Add LDAP settings into settings.py of controller and getting all values of attibutes from etcd.
• Activating the LDAP with something like this:

deisctl config ldap set host=ldap.domain.com
deisctl config ldap set dn="dc=ldap,dc=domain"
deisctl config ldap set user-search="ou=Users,dc=my"
deisctl config ldap set group-search="ou=Groups"

or

deisctl config platform set ldap="ldap://ldap.domain.com:ou=Groups,ou=Users,dc=my,dc=ldap,dc=domain"

• The user will make a register with the user/password of LDAP and the register will make a verification if ldap is enabled and instead of creating a new user he will make a copy (avoiding that every time when the user makes login the controller go to de LDAP to authenticate the user).
• The user will be replicated in deis users database.
• The user will make a normal login, receive the token (now with a expiration time)

I really dont know if this is a good implementation, so lets discuss about this before we start to implement.

[bacongobbler]

IMO I think that external auth libraries are great, but we should probably be laying out the groundwork first. In order to allow community members to plug in their auth solutions like LDAP, we should think of how we can break out the authentication system and make it extensible. Right now the auth system is anything but extensible, which means that LDAP support would be largely untested... Not exactly what we want as a post-stable feature.

[phspagiari]

I understand and agree with you @bacongobbler. So we need to "decouple" the actual auth model in a new module and make it extensible for any new auth solutions like Oauth, LDAP and more.

Actually the auth is under api.views using the api.serializers.UserSerializer. The idea is modifying all to a new module like api.auth and make this extensible for new auths ( class LdapAuth(api.auth) for ex. ) right? We cant forget that we are using django and he have your own user model and all new auth models have to use his User model.

[mvanholsteijn]

I agree with @bacongobbler that Deis should have a pluggable authentication system and not be limited to LDAP. I would need support for SAML and Oauth identity providers for my customers.

[bacongobbler]

@phspagiari correct. I'd imagine that the end result would look very similar to Django's customizable auth backend, where community members could simply compile their own auth library into the controller, modify some django config settings and they're good to go.

[phspagiari]

@bacongobbler and if we "remove" all the auth model of deis and use 100% the auth backend of django?
Since we are using django with a layer of serialization / simplification of the user, we can moving all to the auth.backend of django and implement the others auths simply adding new backends.

(I must say that I'm new to django and used Flask always 😄 )

[phspagiari]

Well... Using what I said above I make a PoC in gist with a README and a patch for deis-controller to use LDAP modifying the minimal necessary at settings.py and using the etcd and the confd.

https://gist.github.com/phspagiari/76165b35bae1b8e5a891

Its working, if we can find a better way to implement this and make this a mergeable code will be good.
I dont see the need to refactoring all the auth model to implement this or another auth models.

@bacongobbler @lorieri @carmstrong @mvanholsteijn

[bacongobbler]

true. I think that's something that we need to properly handle in the future but shouldn't be a blocker.

[carmstrong]

Its working, if we can find a better way to implement this and make this a mergeable code will be good.
I dont see the need to refactoring all the auth model to implement this or another auth models.

I agree with that - let's see what the changes look like. If it's a clean implementation, we can implement that in the short-term without a major auth refactor.

[lorieri]

👍

[mboersma]

Fixed by #3174.