We are attempting to configure SSO on our instance of Splunk to allow users to enter the Splunk app through our own product application (i.e., a button inside our application that will instantiate a login to our Splunk instance and then display the app that matches the login used).
We've followed the tips in the troubleshooting doc ( http://docs.splunk.com/Documentation/Splunk/6.0.1/Security/TroubleshootSplunkSSO 😞 we've added the load balancer IP address (which sits in front of our Splunk instance) to the web.conf trustedIP
list; we've turned on tools.proxy.on
; the cookie appears to be correct. We had tried setting the splunkd trusted IP to the host IP, but that broke Splunk's ability to validate the username we passed in the X-Remote-User header; we don't understand why the proxy and the host IP should be the same (you wouldn't want the proxy running on the same server as Splunk itself).
Currently, we don't have the proxy server configured to send the HTTP header, but we're using the permissive mode, so I don't think that should be an issue (i.e., it shouldn't break the entire web UI).
When we try to go to our Splunk web UI (either through the URL that runs through the load balancer or by going directly to the Splunk server's IP address on port 8000), it tries to redirect to the localhost - on the machine that you're trying to access from (i.e., my PC, my coworker's PC, etc.). This works fine if you're on the Splunk server itself, but it breaks on other machines ("Firefox can't establish a connection to the server at 127.0.0.1:8000."). This appears to occur any time a 303 redirect occurs (e.g., if you go to http://my.ip.ad.dr:8000 and it redirects to the login prompt, or after you log in and it redirects to the Search app, and after it redirects to the Search app and then redirects to the search view).
Anyone else run into this? How did you fix it?
server.conf
trustedIP=127.0.0.1
web.conf
SSOMode = permissive
tools.proxy.on = True
trustedIP = 10.110.68.254
remoteUser = X-Remote-User
We needed to set up the "X-Forwarded-Host" header on our load balancer to allow requests directly to our web UI (outside of the proxy) to maintain web UI URL instead of being rewritten to the localhost.
We needed to set up the "X-Forwarded-Host" header on our load balancer to allow requests directly to our web UI (outside of the proxy) to maintain web UI URL instead of being rewritten to the localhost.