SSO without an Active Directory or LDAP provider

(Hi all–welcome to the latest installment in the series of technical blog posts from members of the SplunkTrust, our Community MVP program. We’re very proud to have such a fantastic group of community MVPs, and are excited to see what you’ll do with what you learn from them over the coming months and years.
–rachel perkins, Sr. Director, Splunk Community)

Hello everyone!

I am Michael Uschmann, one of the members of the SplunkTrust.

Lately I was annoyed by the fact that I had to enter my login on my Splunk DEV VM after a meeting or break. So, I thought ‘Why not setup SSO on this Splunk instance so I don’t have to enter my password again?’ But there was this small problem: I don’t have an AD or LDAP server running on my VM – bummer.

Docs and Apache to the rescue!

The docs provide an excellent overview about SSO will work and what to consider:

http://docs.splunk.com/Documentation/Splunk/6.3.2/Security/HowSplunkSSOworks#How_Splunk_processes_the_proxy_request

But the most important statement from the docs is this:

If the IP is trusted, then splunkd uses the information contained in the request header and conducts the authorisation process.

This is the key to get SSO function. So, how do I configure this?

The .conf files needed

I have to change the server.conf to include the following option:

trustedIP = <IP address>
* All logins from this IP address are trusted, meaning password is no longer required
* Only set this if you are using Single Sign On (SSO)

So, my server.conf includes this:

[general]
trustedIP = 127.0.0.1

The next config file I have to change is web.conf:

SSOMode = [permissive | strict]
* Allows SSO to behave in either permissive or strict mode.
* Permissive: Requests to Splunk Web that originate from an untrusted IP address are redirected to a login page where they can log into Splunk without using SSO.
* Strict: All requests to splunkweb will be restricted to those originating from a trusted IP except those to endpoints not requiring authentication.
Defaults to "strict"

trustedIP = <ip_address>
* Trusted IP. This is the IP address of the authenticating proxy.
* Splunkweb verifies it is receiving data from the proxy host for all SSO requests.
* Uncomment and set to a valid IP address to enable SSO.
* Disabled by default. Normal value is '127.0.0.1'
* If appServerPorts is set to a non-zero value, this setting can accept a richer set of configurations, using the same format as the "acceptFrom" setting.

tools.proxy.on = [True | False]
* Used for running Apache as a proxy for Splunk UI, typically for SSO configuration. See http://tools.cherrypy.org/wiki/BehindApache for more information.
* For Apache 1.x proxies only. Set this attribute to "true". This configuration instructs CherryPy (the Splunk Web HTTP server) to look for an incoming X-Forwarded-Host header and to use the value of that header to construct canonical redirect URLs that include the proper host name. For more information, refer to the CherryPy documentation on running behind an Apache proxy. This setting is only necessary for Apache 1.1 proxies. For all other proxies, the setting must be "false", which is the default.
Defaults to False

remoteUser = <http_header_string>
* Remote user HTTP header sent by the authenticating proxy server.
* This header should be set to the authenticated user.
* Defaults to 'REMOTE_USER'.
* Caution: There is a potential security concern regarding Splunk's treatment of HTTP headers.
* Your proxy provides the selected username as an HTTP header as specified above.
* If the browser or other http agent were to specify the value of this header, probably any proxy would overwrite it, or in the case that the username cannot be determined, refuse to pass along the request or set it blank.
* However, Splunk (cherrypy) will normalize headers containing the dash, and the underscore to the same value. For example USER-NAME and USER_NAME will be treated as the same in SplunkWeb.
* This means that if the browser provides REMOTE-USER and splunk accepts REMOTE_USER, theoretically the browser could dictate the username.
* In practice, however, in all our testing, the proxy adds its headers last, which causes them to take precedence, making the problem moot.
* See also the 'remoteUserMatchExact' setting which can enforce more exact header matching when running with appServerPorts enabled.

My web.conf includes this:

[settings]
SSOMode = permissive
trustedIP = 127.0.0.1,192.168.56.1,192.168.56.101
remoteUser = REMOTE_USER
tools.proxy.on = false

Why did I use those options? Let me explain a bit:

SSOMode = permissive

I chose this setting because sometime other members of out team will login to my Splunk instance and I don’t want them to use my SSO settings.

trustedIP = 127.0.0.1,192.168.56.1,192.168.56.101

I chose this setting because my VM has multiple interfaces and Splunk is listening on both IP’s.

remoteUser = REMOTE_USER

The default setting for this option.

tools.proxy.on = false

Even though the docs suggest it to be set to true, I found that it will only work if you set it to be false – But only for this special use case! Stick to the docs if using SSO with AD or LDAP.

Last but not least I need an Apache server and I need to configure it as well. Since this Apache will be used sole for reverse proxying to Splunk I did use a location config like this:

<Location /> 
ProxyPass http://127.0.0.1:8000/
ProxyPassReverse http://127.0.0.1:8000/
Header add REMOTE_USER "admin"
Header add Accept-Language "en-GB"
RequestHeader set REMOTE_USER "admin"
RequestHeader set Accept-Language "en-GB"
</Location>

As you can see I did set the REMOTE_USER to be the Splunk user admin, so I will always be authenticated as Splunk user admin on my Splunk Instance. You can also see a little trick to set another language default other then en-US 😉

So, where else can this be used?

For example it can be used for NOC or ITOC wallboards, where you configure the Apache on different ports for each wallboard and use dedicated users for each board, which then loads a default dashboard in Splunk.

In the end it is up to you where else you can use it … just keep a common sense of security in mind, like securing the Apache port with access restriction.

cheers!

----------------------------------------------------
Thanks!
SplunkTrust