Closed palourde closed 9 years ago
@palourde I'd probably push back on this, use a proxy that already supports these authentication methods. Bloat.
if you do it in a proxy, you can't have granular access on a RBAC basis. Which is one of our needs. Which is why we want to implement it.
:+1:
+1 and concur with @failshell
Are people using CAS/AD auth for API or old-dashboard currently, without fronting those? While not impossible, I suspect adding RBAC to Uchiwa would be a rather significant change to the codebase and introduce a lot of potential if/then checks.
Not dismissing your feature request (your needs aren't my needs, and I respect that) -- but how would one logically break down RBAC within Uchiwa, without adding massive complexity to management of roles?
Hi @xyntrix
I'm working with faillshell so adding CAS/AD auth would definitively be a nice feature to have, in our situation.
I didn't had time to look more at this feature and it won't a priority, at least during my free time. I hope there's some kind of npm modules that would offer such authentication because I do not intend to build it from scratch.
Also, the RBAC approach would be an another feature in my mind and if it happen, it would have to be a simple and clean implementation.
+1 to adding this support.
@portertech Attempting to add a proxy that supports both LDAP auth and the websockets used by socket.io is troubling to say the least. Nginix has websocket proxying, but issues w/ the LDAP auth module. Lighttpd supports LDAP, but the websocket module is unsupported and has issues. Trying to use a nice lightweight proxy instead of something like full Apache 2.4 or ATS. Even the patch for Uchiwa to disable websockets as a socket.io transport no longer works since moving to express.io (wtf?)
Has anyone had any success with a setup like this?
Google authentication would be awesome
@Infraded @palourde with websockets being removed in the next version of Uchiwa, is this feature more suited to be implemented with a proxy as @portertech had suggested?
@amdprophet I agree that advanced authentication should probably be handled by a proxy, now that websockets are going to be removed. I'm leaving this issue open as a reminder to test and document some solutions.
@palourde @amdprophet Just some tough on the matter. Authentication should happen at the lower point possible, especially for microservices or you should have some sort of external SSO or an external service setting your JWT (or any other type of auth token).
If you relay only on the external proxy anyone who can access the host has access as admin to the api and so has admin right on all the remote sensu instances leaving some space to malicious activity. It's like leaving the config file with the clear password as world readable on the file system and in my opinion should be avoided, especially on machines that serve "web" content.
What do you think about that ?
For anyone interested, we implemented this feature into the Sensu Enterprise dashboard. It might be, at some point in the future, released as an open-source feature into Uchiwa.
@palourde Any updates on when the LDAP authentication feature will make it into open-source Uchiwa?
@tavorincon at this time there are no plans to implement LDAP authentication in Uchiwa. LDAP-backed Role-based access controls are available now in Sensu Enterprise (see here for docs: https://sensuapp.org/docs/0.19/enterprise-dashboard-configuration#role-based-access-controls-rbac), and Sensu Enterprise now comes with a 14-day risk-free trial if you would like to try it out.
Gentlemen? What is the status of this a year later? Is the feature supposed to be in the non-Enterprise Uchiwa by now (0.16.0)? Looking under our uchiwa.example.net/#/info I saw a bunch of LDAP-related settings. I now have them populated to the best of my understanding, but I'm still not asked to login, when I load the dashboard...
We are cheap here and will, probably, use an Apache-proxy if we have to... But if it is supposed to work, I'd rather avoid the proxying... Please, advise. Thanks!
We're going to use oauth2_proxy in the meantime, but would have liked a built-in OAuth in a product as mature as uchiwa (And switching just to Entreprise for Auth seems a bit overkill to be honest)
@Esya I recently implemented oauth2_proxy
with Uchiwa and ran across similar issues. I believe most of the benefits that basic auth would give you are implemented in uchiwa-web. I'm looking into a theme that will play nicely with oauth2_proxy
.
If you're interested in collaborating or providing testing and feedback, please contact me via the email in my profile :)
I have created a working environment that auth's against AD via github.com/go-ldap/ldap (https://github.com/go-ldap/ldap).
I have posted a comment in https://github.com/sensu/uchiwa/issues/295 looking for requests on how to structure the code for a pull request.
Support authentification with CAS, AD, etc.