Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make auth providers fully pluggable #2232
Currently Graylog does not support pluggable authentication providers.
This includes the following tasks:
This was referenced
May 13, 2016
We've been using a function called AAA (Form Fill SSO) in Citrix NetScaler which stopped working with version 2.0. What it does is send username and password to the form action url and signs in the user, but seems like it has changed quite a lot since the earlier version of graylog and now is required to send the username & password in json format wich I haven't seen before.
Adding REMOTE_USER header would work in this case, but since I guess it's a while until that is supported. Is there any URL I can send the username and password form in version 2.0 to get the SSO working, or is it completely removed?
@simongottschlag Sorry I missed your earlier comment.
tl;dr: in 2.0 it does not work, sorry, but we'd like it to work in 2.1
The reason it stopped working is because the web interface is now using Ajax do establish the session. It does so because it stores the session in local storage rather than a cookie as in pre 2.0 versions (this has to do with the merge of the web interface process and the server and how cookie sending works against multiple backends...)
It's good timing that you bring this up because I'm just now working on being able to establish sessions without actually submitting the login form.
To log in a user needs to enter her credentials into the form which is rendered client side in 2.0 (the reason this no longer works for you).
What happens internally is the following
The proposed change is that the validation step exposes credentials transported in the HTTP request headers to the authenticators which can trigger creating a new session implicitly.
The requirement was only to allow specifying user principal ('username") and optionally other attributes fetched from an external system.
@kroepke No problem! I should learn to tag (@).. Still new to GitHub. :)
I think this will work great. I would recommend you adding the possibility to limit the possibility of using this to only specific IPs/subnets (for example the NetScalers IP). If the request comes from a valid IP and has the header X-Graylog-Username="simon" then it should do a lookup for the username in LDAP and authenticate the user.
I have another question regarding how it's done today. Is the way you are doing the authentication something that will be (or maybe already is) be used in "modern" web development? Should we try and get NetScaler to handle this kind of authentication as well? Is this way of authenticating the user called anything special?
I am able to send the users credentials (username + password) in almost any way to the web server using the NetScaler. For example, I can look for a cookie, header or something else and if it's missing send the credentials to the web server. If you could help me understand how the POST should look like and what kind of token I should be looking for then I'd be able to try it out.
Thanks for your great answer. I'm sure that the httpheaders plugin will work!
@simongottschlag Not sure if this has a specific name at all, it's simply a common pattern for single sign-on (SSO) systems to integrate with third party products that do not have explicit support for them.
If at all possible, I'd avoid sending passwords around. In the case of Graylog it won't even make much sense, since there will be no stored password for the user anyway. All we'd need is a username and potentially an email address.
@kroepke I was thinking about what it the current method is called. Would be good to know so we can integrate it as well with the current AAA/SSO solutions (since I guess more and more systems will be using it in the future).
I took a look at the current development of graylog-plugin-auth-httpheaders and it looks good! One question thought, would it be possible to add something like "require IP" to use http headers? Making sure that the requests with the user header are only accepted when coming from for example the NetScaler.
Keep up the great work! :)
Simon's previous point is essential. If you for instance base authentication on magic header, you have to make sure it came from the authentication source instead of malicious user. Some authenticating proxies for example sign their tokens, but simple IP restriction should be enough for most setups. The trusted_proxies setting could be used for that.