cachethq
LDAP Authentication
Hey guys,
i've been wondering if you would ever implement a LDAP Authentication.
Kind regards,
It's something that would certainly be of great use to Cachet. Although... it's a pretty big job.
I'll take this on this week. Any specifics before I start? I'll add support for multiple LDAP servers (can either be an array of servers, or a set amount...4 maybe?)
We have nothing in mind, so please make a start and we'll advise through your PR.
We'd accept a PR for this, but we don't have the time to allocate to it I'm afraid.
So, I think this or #213 should remain open and tagged as a future road-map item instead of closing the :octocat: Issue. That will communicate to others that they could potentially pick it up. Closing the issue signals to most folks that it was either invalid or completed -- this falls somewhere in the middle (could be worked on, but not a small task). :heart:
Excellent! I figure @jabarihunt probably got wrapped up in other things. Here is a CodeIgniter based app that leverages some LDAP components for authentication that could likely serve as a starting point. I'd propose:
- [ ] Add a basic LDAP component to the Docker install with some default users (this one looks scriptable)
- [ ] Select a composer package work with LDAP (Symfony has one)
- [ ] Research intercepting the process check against LDAP if configured before falling back to the database
Some things to consider:
- Users should likely be configured first in Cachet before allowing access.
- Alternatively, the BaseDN would need to be configured to only permit certain users to access (user record would be created on new sign in via LDAP).
- If the second scenario is used, promotion to admin would need to be limited to a configured database user.
- An LDAP user should not be permitted to set a password, perhaps not able to update their first name or last name.
LDAP adds a lot of complexity so this needs to be handled correctly the first time it's implemented. We can absolutely work together on a PR for this.
just a thought... would setting up HTTP auth be easier/simpler? That way apache/nginx could be configured to handle auth using whatever mechanism is prefered and Cachet would only need to be able to accept remote_user. If ldap was needed, then the web server could be configured for that.. or saml2 or
That sounds like a not-so-pretty work around @EmilioD; I feel like this, as a feature, is something that should be implemented as neatly as possible – full integration. Not just a bypass of sorts.
I was more thinking that way its more flexible than just ldap. At least in my environment we dont care where/which authentication source we use so long as its once of the options we have centralized. This would allow the devs to focus on the app and allow for admins to focus on auth / config.
i would recommend that no LDAP Support would be enabled... use a radius support instead. You can use radius with all backends and it's a much easier solution
http://freeradius.org/ Yes... it's good with Server where you can configure multiple backends... so cachet need one code implementation to radius only and all can configure his radius instance for his needs.... best Auth solution
No Radius please! :slightly_smiling_face: LDAP is very common need and I don't think anyone wants to setup a radius server just to use Cachet with auth.
My suggestion: accept preauth headers. Then you can have a reverse proxy handle the auth, whether that's LDAP, Radius, or some single-sign-on solution. The proxy would just pass in the username as an HTTP header and Cachet would trust the request was preauthenticated.
fully supporting @segfly suggestion. it would allows easy integration with Azure: https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
@segfly I'm unsure about just 'trusting' the request – that sounds horrible.
That said, I also agree with not using Radius. Seems like an extra step for no real reason.
I think @segfly is recommending the right path forward. Let the web server (what I was recommending) or a reverse proxy take care of the authentication. This way if someone wants radius then they can setup apache/nginx to use radius, if they want ldap/shibboleth/oauth/etc then they can set that up with the web server, independently of the cachet web app.
@ConnorVG
I'm unsure about just 'trusting' the request – that sounds horrible.
This approach is not unheard of, in fact I wish more applications did this and embraced separation of concerns. The security aspect is taken care of if you just ensure no other client can reach Cachet other than the reverse proxy - trivial in a container deployment. The reverse proxy needs to sanitize input and ensure no one is trying to inject the trusted auth header e.g. CACHET_PREAUTH_USER.
I'll see if I can get a PR created for this in the next 1-2 weeks if the idea itself is something that will be approved. @jbrooksuk?
@segfly I am not very familiar with the authentication stack in laravel (I am a lot more old school php), but if someone can point me to where the current user authentication library/module is coming from, I should be able to get remote_user auth working fairly easily.
@jbrooksuk any concerns with us making remote_user authentication an option? That way its up to an admin to configure whatever external authentication mechanism they would like, or use the built in.
@EmilioD To be honest, I don't know either. I have someone on my team who is experienced in PHP, but not necessarily laravel. So we'd be starting from the same place.
@segfly I have a few folks here as well who have done work using Laravel, Ill ping them. In the meantime it appears as though Laravel already has the capabilities: https://laravel.com/docs/5.4/authentication#authenticating-users
I think this needs proper thought before we implement any changes to the user system.
There are multiple levels of integrations for LDAP integration. I would suggest to implement it with a Step by Step approach. The basic is LDAP authentication, e.g. the username is in the Cachet database and the password authentication routed to the backend LDAP server(s). This should address issues for many users and should be a straight-forward enhancement. Then it will be the full integration, such as LDAP group integration, user account auto provisions and attribute mappings, the whole nine yards.
My 2c: Groupbased authentication against LDAP/AD would be very nice. Ideally, users don't need to be known to cachet, and user maintenance would be lot easier for the admins.
