We're using Shibboleth at my institution; it does require use of the Splunk SSO capabilities.
Shibboleth provides an authentication system via an Apache module which sets additional environment variables in the HTTP header. The onus is then on the application to do something (i.e., to provide authorization) with that information. At a bare minimum, Shibboleth will set REMOTE_USER. Since Splunk runs its own web server, you have to then pass this to Splunk's web server via an Apache proxy listening on the front-end. Users will connect to the Apache server, not directly to the Splunk web server. This adds some complexity because you have to make sure to tune your Apache installation for your usage, and make sure that you have enough memory on the server to accommodate both Splunk and Apache.
Depending on the Shibboleth IdP (identity provider) at your institution, it may also support a "groups" attribute of some type similar to LDAP groups. Our installation does not yet support this, unfortunately, so I only handle the authentication within Shibboleth, then handle role management within Splunk by creating users and groups there; an authenticated username provided in the HTTP header by Shibboleth has to match up to the username in Splunk. One tricky thing is that the Shibboleth username is usually in the form <user>@<domain> rather than <user> .
The most complex part of this is getting the Apache proxy to pass the REMOTE_USER variable to the back-end Splunk web server reliably, because REMOTE_USER is handled as a special case by mod_proxy on some versions of Apache. To do that on our install I had to use this in the default Apache config (i.e., outside of any virtual host configuration):
<Location />
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
AuthGroupFile <your group file>
Require group splunk
</Location>
The "ShibUseHeaders" line is critical; if for some reason you can't get your Apache config to pass REMOTE_USER through the proxy, Shibboleth will provide a few other HTTP header variables, one of which you might be able to use to identify the user. The exact set of variables passed depends on the Shibboleth IdP's configuration--you can use the "printenv.cgi" script in a Shibboleth-protected directory to view the complete set of available variables (the printenv.cgi script is included with a default Apache install). In my experience REMOTE_USER handling is a special case and doesn't always work, but by default the proxy module should allow other variables in the HTTP header to pass through.
Once Shibboleth is working I use this in the virtual host config for port 443 to proxy all incoming requests to port 443 to the back-end Splunk web server. It's also useful to remap the Splunk logout page to the Shibboleth logout page, which is done via the "logout" lines:
ProxyRequests Off
ProxyPreserveHost On
SSLProxyEngine On
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/en-US/account/logout$
RewriteRule ^(.*)$ https://<splunk>/Shibboleth.sso/Logout?return=https://<shibserver>/idp/logout.jsp [R,L]
RewriteCond %{REQUEST_URI} !^/icons
RewriteRule ^(.*)$ https://localhost:8000$1 [L,P]
where <splunk> is replaced by the Splunk web server's hostname and <shibserver > is replaced by the hostname of theShibboleth IdP.
Following that, I then used this to set up Splunk so it accepted the REMOTE_USER variable using the document listed below (this was the easiest part):
http://www.splunk.com/base/Documentation/4.1.5/Admin/Usesinglesign-onwithSplunk
Not too complex, but not entirely trivial. However this definitely works, we have about 150 users using this configuration.
James
... View more