Using single sign-on

Single sign-on (SSO) lets you use some other web server to handle authentication for Splunk. For this to work, several assumptions are made, as follows:

• Your SSO system can act as an HTTP forwarding proxy, sending HTTP requests through to Splunk.
• Your SSO system can place the authenticated user's ID into an HTTP header.
• The IP of your server(s) forwarding requests is static.
• When given a particular username, Splunk will be able to determine what roles this user is a part of. This is usually accomplished using LDAP, but could also be accomplished by defining users directly through the Splunk UI or via a custom- scripted authentication plugin.

Assuming that all of these are true, the usual approach is to follow these steps:

1. Configure LDAP authentication in Splunk.
2. Configure your web server to send proxy requests through to Splunk: When this is configured properly, you should be able to use Splunk as if you were accessing the Splunk web application directly.
3. Configure your web server to authenticate: With this configured, your web server should ask for authentication, and you should still be asked for authentication by Splunk.

4. Look for the HTTP header containing the remote user: Proxying through your web server, change the URL to http://yourproxyserver/debug/sso.
   You should see your username under Remote user HTTP header or Other HTTP headers.

5. Configure SSO in $SPLUNK_HOME/etc/system/local/web.conf: You need to add three attributes to the [settings] stanza, as shown in the following code:

[settings] 
SSOMode = strict 
remoteUser = REMOTE-USER 
trustedIP = 192.168.1.1,192.168.1.2

That should be it. Usually, the hardest part is convincing the web server to both authenticate and proxy. Use the /debug/sso page to help diagnose what is happening.

There can also be issues with punctuation in the header fieldname. If possible, removing any punctuation in the header name may eliminate unexpected problems.