Make auth providers fully pluggable

[kroepke]

Currently Graylog does not support pluggable authentication providers.
In order to make it easier to integrate with SSO systems or other external authentication/authorization providers, the hardcoded list of built-in providers should be made extensible, configurable from the API/UI and non-core providers should move into plugins themselves.

This includes the following tasks:

• Introduce new binding helper for plugging in AuthorizingRealm/AuthenticatingRealm
• Allow ordering realms from configuration and during runtime
• Refine interfaces to create shadow user accounts based on external authentication realms
• Define interface to configure the SecurityManager

[mikkolehtisalo]

Will it be possible to disable other authentication methods, mainly the default username/password method?

[kroepke]

@mikkolehtisalo Yes, I guess we should be able to do that.

[simongottschlag]

Hi,

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?

Best regards,
Simon

[simongottschlag]

@kroepke Any idea if there's anything we can do about the above?

[kroepke]

@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...)

As of right now I don't think we can have an endpoint that can establish a session that way because there's Javascript that needs to run to store the session.

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.
Here's the current plan, maybe you can think about whether it can solve your problem as well:

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).
In the case an external system (proxy, NetScaler, browser plugin for smartcards etc) already authenticated a user, there will be a header containing the principal for the user.
Graylog will, if explicitly configured to do so, trust that the principal is correct and grant access to the identified user (or create the user account from scratch if it doesn't exist, like LDAP does today).

What happens internally is the following

• Before the UI code runs Ajax calls it tries to validate the session it currently has stored (it does so even when there is no session).
• The response to that GET is either the answer "session is fine, continue" or "session is invalid".
• In case of the latter it then renders the familiar log in screen. Submitting that runs all authenticators and on success creates a session and returns its identifier which the UI saves in local browser storage.
• Logout simply deletes the session on the server and from local storage.

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.
This step would then not only validate an existing session, but could also return a new one, leading the UI to assume the user is logged in.

The requirement was only to allow specifying user principal ('username") and optionally other attributes fetched from an external system.
Now I'm unsure whether the AAA system needs to give you username and password and requires posting something or not, I'm simply not familiar with it.
If it can set a header then the proposed plugin (https://github.com/Graylog2/graylog-plugin-auth-httpheaders once it's ready, nevermind the boilerplate docs etc) should be able to solve your use case, too.

[simongottschlag]

@kroepke No problem! I should learn to tag (@).. Still new to GitHub. :)

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).
In the case an external system (proxy, NetScaler, browser plugin for smartcards etc) already authenticated a user, there will be a header containing the principal for the user.
Graylog will, if explicitly configured to do so, trust that the principal is correct and grant access to the identified user (or create the user account from scratch if it doesn't exist, like LDAP does today).

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!

[kroepke]

@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.

[simongottschlag]

@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! :)

[mikkolehtisalo]

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.

[kroepke]

@simongottschlag @mikkolehtisalo Yes I agree, I have that on my list already.

@simongottschlag Well, Splunk simply calls this SSO, so we will likely do the same to make it less confusing for migrating users. I don't think there is any other name for the technique, tbh.

[simongottschlag]

@kroepke Ok, thanks! Do you think this plugin will be available in the next alpha? Keep up the great work!

[kroepke]

@simongottschlag Yeah, the PR is currently in review and I think it'll land in the next release.

[kroepke]

@mikkolehtisalo @simongottschlag for reference the trusted_proxies support is done in Graylog2/graylog-plugin-auth-sso@9077714

since it requires a post-beta.1 change it will only work with the next release. We'll provide the plugin binary at that point as well.