I'm about to need to do something similar. We're using an IDP (RSA SecurID Access) that can't seem to pass through multivalued attributes except as a comma-delimited string, which Splunk doesn't want to parse as a group list. The IDP is very limited so there's no easy way to pass useful role data from AD into the SAML assertion. We're currently using AD/LDAP authentication successfully, but having true SSO would be nice so I can be lazy and not have to type my password.
I think I'm going to have to use header-based SSO instead. This is a bit complex, because it involves setting up a proxy and running the SP there instead of using Splunk's built-in SAML support. Fortunately I have experience there -- I already have a working setup to do something similar for OWA. In that case it's an Apache2 proxy in front of Exchange, with a Shibboleth SP and a special module I wrote to convert the assertion to a Kerberos ticket (S4U2Proxy aka Kerberos-constrained delegation) to pass to OWA.
The setup for Splunk will be a bit simpler than that -- Splunk doesn't need Kerberos and can just trust the proxy to set an HTTP header with the authenticated username.
As "Proxy SSO" doesn't include any kind of authorization data in the headers, you can continue to use LDAP for that, according to the documentation at least.
https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/HowSplunkSSOworks
https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/ConfigureSplunkSSO
So, Apache2/mod_shibboleth sits as a proxy in front of Splunk and just passes on a header with the username. The proxy can even be on the same machine and listen on 443 if you want (leave Splunk on 8000). It's not ideal, but it should work.
Will update with any gotchas or caveats once I've tried this.
... View more