Splunk via Shibboleth

Splunk Employee
Splunk Employee

Can I use Shibboleth for Splunk authentication?

Tags (1)

Thanks for the tip jervin.

We were able to use splunk sso w/ shibboleth using this apache config:

   <VirtualHost _default_:443>
DocumentRoot /var/www/
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/ssl_access.log combined
SSLEngine on
SSLCertificateFile    /etc/ssl/certs/myhost.pem
SSLCertificateKeyFile /etc/ssl/private/myhost.key
    <Location />
            AuthType shibboleth
            ShibRequestSetting requireSession 1
    ShibUseHeaders On
            require ou staff
ProxyRequests Off
<Proxy *>
    Order deny,allow
    Allow from all
ProxyPass /
ProxyPassReverse /

We couldn't get apache to pass REMOTE_USER so we told splunk to map the 'uid' variable passed by shib instead in $SPUNK_HOME/etc/system/local/web.conf:

    trustedIP =
    SSOMode = strict
    remoteUser = uid
    login_content = <b>ACCESS DENIED</b>: You are not authorized to access Splunk!

If the user successfully authenticated to shib but they're not authorized to access splunk then they're prompted to authenticate in splunkweb. Not sure if it's the best way, but I simply added an ACCESS DENIED message in the login screen (login_content parameter).

Also, the 'logout' link in splunk is essentially useless now with SSO. You can remove it by navigating to 'Splunk->Manager->User Interface->Views->App Context: search->dashboard' and editing this module:

   <module name="AccountBar" layoutPanel="appHeader">
         <param name="mode">popup</param>


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

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):

Not too complex, but not entirely trivial. However this definitely works, we have about 150 users using this configuration.



I see that you use ShibUseHeaders On while others use RequestHeader set REMOTE-USER %{REMOTE_USER}s. The big difference is that ShibUseHeaders returns many headers which can be used elsewhere (like ou, or group or memberOf), while the latter only returns the REMOTE_USER header. But Note that the Shibboleth Documentation gives the following warning about ShibUseHeaders: ''Use of this option should be avoided. Be sure to review the topic on spoof checking if you enable it.''

0 Karma

Splunk Employee
Splunk Employee

I think there would be two ways to accomplish that. The first would be to provide a scripted authentication mechanism to parse the returned SAML assertion.

The second would be to piggyback off an existing SP through Splunk's SSO

Don’t Miss Global Splunk
User Groups Week!

Free LIVE events worldwide 2/8-2/12
Connect, learn, and collect rad prizes
and swag!