Hi, I’m using apache setup as a reverse proxy, so I can serve graylog up using SSL to my end users, and because I was hoping to add an additional layer of authentication before opening up graylog to the public internet for my users to consume. I don’t have the option of using a VPN, or using SSH port forwarding to avoid putting graylog on the public internet. My goal was to get a 100% independent layer of authentication that didn’t rely on any graylog code whatsoever, instead relying on established apache authentication methods, before I’m even asked for my graylog credentials.
However, I quickly learned that graylog uses basic authentication (and the Authorization) header for itself, so there doesn’t appear to be a way for me to do any basic/digest auth. Is there any way around this?
I’m open to alternatives, including other forms of apache authentication (open id?), but I don’t have any experience with those, so I’m not sure if they also use the authorization header. Has anyone solved this?
Sorry, my question was not so much “is it mandatory that graylog use basic auth”, but more whether there was a way to accomplish what I’m looking for without breaking graylog
For example, I read an older thread from Feb 2016 which talked about setting up the same username/password for a user in both graylog, and apache’s basic auth, which prevented graylog from even presenting a login screen. The thread mentioned is actually trying to “fix” that he has to unset the Authorization header, which requires logging into both http basic auth, and graylog. I personally don’t care if I have to login to both apache basic auth, and graylog, or just apache basic auth, but I’m unable to get my installation working in the way he describes.
Should this still work? Is there something I’m doing wrong when setting up the passwords in http basic auth? Ie: do they need to be salted first or something?
I’m open to other workaround ideas as well. I’m hoping I’m not the only person who wants to an apache layer of authentication to their publicly available install.
Thanks for the suggestion Jochen, Can you elaborate on how the SSO plugin would allow me to add an additional layer of apache authentication, preferably along with graylog authentication? Or maybe elaborate more on your suggested use of SSO plugin?
Also, the bug indicates that his use case should have worked, and using SSO was suggested as an alternative. Can you, or anyone else give me some more details around whether the use case in that bug should still work, and why or why not? Has something changed since then that would prevent using basic auth in apache?
As for other methods, thanks for the suggestion to use certificate auth. I’ve considered that, but I’d really like to avoid the tech support and maintenance overhead associated with maintaining a CA, deploying certs onto peoples browsers, etc. That is my fallback plan. But it just seems like there has to be a better way
Hi Jochen, Thanks for the helpful response. I have google though, and haven’t had a problem finding links to documentation I was hoping you could tell me how you envision SSO solving my problem. From what I can tell, the SSO plugin just allows me to choose a header which contains a username, allowing you to bypass graylog authentication.
My goal is not to bypass graylog authentication, so I don’t think the SSO plugin helps me.
My goal is to add an additional layer of authentication via apache. If anyone has any suggestions on how to do that, preferably using http basic auth, I’d love to hear them. I imagine this is a common requirement, and I’m interested in hearing from graylog users how they accomplished this.
You didn’t really tell us what your current configuration is, but you can use an Apache or Nginx reverse proxy with saml2.0/shibb authentication to further protect things.
Alternatively, there is also the LDAP integration, which is what we use. The LDAP server specified in the configuration would actually be an auth proxy that forces a 2FA on a mobile device.
My config is a vanilla graylog install using local authentication, nothing extraordinary. It’s sitting behind an apache reverse proxy, which handles SSL to the public facing internet end users.
When you mention saml2.0 and LDAP, you are doing those using apache modules, correct? Not via graylog?
Are you still doing graylog authentication, or are you using SSO to bypass the graylog login process?
@TJgrayD Yeah, you wouldn’t use both of those for the AUTH, so you’d need to find which one you feel comfortable maintaining, choose one. SAML2.0 would be a redirect after auth using the Apache module to the Graylog login. LDAP integration, on the other hand, is native to Graylog. With this, one would login directly at the Graylog page, and configure it within the GUI under the Authentication section.
LDAP can be a local instance with user accounts, or an externally hosted infrastructure (AD, Azure, etc), but remember that all this does without the AUTH proxy is that it just provides another directory with user accounts. So LDAP only fixes your problem if you use the proxy, first. There are many different options for this, but Duo is what we use.
OK, so I can finally put this one to rest. My solution in the end was to add the following pieces to the puzzle: mod_auth_openidc, auth0.com, our existing google apps domain. The value here was that I didn’t have to manage certs and support OS and browser problems, and my users are already going to be logged into and using their google account heavily, so this didn’t add much headache factor.
First, let me state, I’m by no means a oauth expert, and this was my first time doing it, and it’s likely I did something wrong. I welcome any comments, corrections, and improvements, but since this forum shuts the threads down after 14 days that seems unlikely, so oh well, use at your own risk, don’t use in production, blah blah don’t get mad at me
Basic Concepts and Notes:
I’m using the mod_auth_openidc module for apache (i’m using 2.2, but its also available for 2.4).
Auth0 is a SAAS authentication service, that can do Oauth authentication, based on your login status of third party services (AD, facebook, google, salesforce, their own database, touch authentication, etc).
We already used google apps, so it made sense to use google, but you could use other providers as well.
I’m not doing graylog SSO, so the users still have to login to graylog. I consider this a feature, not a bug. Some will disagree with me That being said this method could easily be used for graylog SSO with some header rewriting, and careful consideration.
When a client authenticates with a supported Auth0 third party, auth0 gathers information about that user from the third party, and then sends that information to the mod_auth_openidc module (Name, email address, country, etc). You can then decide which of that information you want your “require” statements to pay attention to.
You can test what information is sent to mod_auth_openidc by going to Auth0.com > Connections > Social > Google > Click the “try” button. You’ll authenticate to google, then they’ll spit out the information they receive, so you can decide what regex rules you want to use in apache.
Auth0 instructions:
Create a “client” from the Auth0 web UI, and choose “apache” from the client type. This will give you basic instructions.
YOU’LL LET ALL GOOGLE USERS IN BY DEFAULT if you follow the apache instructions (the “Require valid-user” statement) exactly as they are on the site, but its easy to fix that. just make sure you test and are satisfied when you’re done.
No need to do the folder stuff in the example for this simple use case.
Under the settings tab when you’re creating the app, I literally only filled out one option, and left everything else 100% untouched. This means some of the more “advanced” options like logout, etc don’t work. I’m ok with that, might improve it at some point.
Once your client is created, you can look and see wh
Apache instructions:
Install mod_auth_openidc - This can be easy or a PITA depending on your platform. There is a little bit of a dependency tree to chase down, but that’s beyond the scope of this doc.
I have a dedicated “graylog.conf” config file for graylog specific settings, and this is a slightly modified version of it:
LoadModule auth_openidc_module modules/mod_auth_openidc.so
Listen 9900
#####mod_auth_openidc specific settings
OIDCProviderMetadataURL https://mydomain.auth0.com/.well-known/openid-configuration
OIDCClientID <WillbeprovidedbyAuth0>
OIDCClientSecret <WillbeprovidedbyAuth0>
OIDCScope "openid name email"
OIDCRedirectURI https://graylog.domain.com:9900/redirect_uri/
OIDCCryptoPassphrase <passwordToEncryptTheSessionInformationOnTheCookie>
######
<VirtualHost *:9900>
ServerName graylog.domain.com
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Location />
#####mod_auth_openidc specific settings
AuthType openid-connect
#Multiple Require claim statements are treated as OR statements.
Require claim email:specificuser@domain.net
#regex allowing any @yourdomain.com email address
Require claim "email~\S+@yourdomain.com$"
######
RequestHeader set X-Graylog-Server-URL "https://graylog.domain.com:9900/api/"
ProxyPass http://graylog.private.domain.com:9000/
ProxyPassReverse http://graylog.private.domain.com:9000/
</Location>
ErrorLog logs/graylog_error_log
CustomLog logs/graylog_access_log custom
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Authorization}i\"" custom
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES
SSLCertificateFile /etc/letsencrypt/live/graylog.domain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/graylog.domain.com/privkey.pem
ServerName graylog.domain.com
SSLCertificateChainFile /etc/letsencrypt/live/graylog.domain.com/chain.pem
</VirtualHost>
I hope this helps someone who is in the same boat as me. It’s a little bit of PITA, but having the additional layer of authentication is worth it to me.
