Configure single sign-on with SAML
You can configure the Splunk platform to use the Security Assertion Markup Language (SAML) as an authentication scheme for single sign-on (SSO), using information that your supported identity provider (IdP) supplies.
The Splunk platform supports many different types of identity provider for logins using SAML for authentication. You can configure the platform with settings that are specific to your IdP. You can also configure certificates and encryption for Splunk Enterprise so that communication between Splunk Enterprise and the IdP is secure. Splunk Enterprise supports the decryption of assertions that it receives from the IdP when you configure the IdP to encrypt those assertions.
Prerequisites for configuring SAML as an authentication scheme for single sign-on
Before you can configure SAML as an authentication scheme for single sign-on, you must have the following:
- A running Splunk platform instance that has access to the supported IdP
- You must have administrator access to this instance to configure the SAML authentication scheme for SSO
- The user you use to log into the platform must hold a role with the
- The Splunk platform instance must be able to contact the IdP over the network
- An IdP that is SAML v2-compliant
- The IdP must be able to provide the
- There is native support for IdPs that have support for Attribute Query Requests (AQR)
- There is support through authentication extensions for some IdPs that do not have support for AQR
- Supported IdPs include but are not limited to PingIdentity, Okta, Microsoft Azure, Active Directory Federation Services, OneLogin, Optimal, and CA Siteminder
- The IdP must be able to provide the
Additional requirements for configuring SAML as an authentication scheme for single sign-on in Splunk Cloud
- Splunk Cloud supports only IdPs that send a SHA-256 signature in SAML messages. You are responsible for the SAML configuration of your IdP including the use of SHA-256 signatures.
Configure the Splunk platform to authenticate into your IdP using SAML
The following instructions are high level, and presume that you have access to Splunk Web. If you prefer, you can also configure SAML SSO using configuration files, see Configure SAML SSO using configuration files.
You might need to perform additional configuration for your IdP, or use the procedures for a specific IdP instead. If you are unsure as to what values are appropriate for your IdP, file a support case if you have an entitlement with Splunk, or ask a question on Splunk Answers if you do not.
Splunk Enterprise always outputs usernames in lowercase in communications with an IdP. If your IdP requires case preservation in in usernames, you can change the username to lowercase in the IdP or configure the IdP to accept the lowercase version of a username.
When you configure a search head to use SAML as an authentication scheme, you must re-enter your credentials to access saved searches after a restart of the search head.
Configure single sign-on using SAML as an authentication scheme
- Log into the Splunk platform as an administrator level user.
- From the system bar, click Settings > Authentication Methods.
- Under External, click SAML. A link Configure Splunk to use SAML appears.
- Click Configure Splunk to use SAML. The SAML configuration dialog box appears.
- In the General Settings section of the "SAML configuration" dialog box, supply the appropriate information to access your IdP. You must supply at least the following values in the "General Settings" section:
- Single Sign-on (SSO) URL
- IdP Certificate Chains
- Issuer ID
- Entity ID
- (Optional) In the Alias section, supply the three aliases as provided by your IdP, if your IdP provides those aliases:
- Role alias
- RealName alias
- Mail alias
Configure single-sign-on using SAML as an authentication scheme for specific IdPs
Splunk has written instructions on how to configure single-sign on with SAML on various identity providers. These instructions are helpful for customers who use these IdPs, but this list not represent the full list of IdPs that Splunk supports for authentication using SAML. The Splunk platform can authenticate using any IdP that is compliant with SAML version 2.0.
- See the following links for instructions on how to configure the Splunk platform to use SAML authentication for a specific IdP:
- Map SAML groups to Splunk roles. See Map SAML groups to Splunk Enterprise roles for instructions.
Configure automatic decryption of SAML assertions from an IdP
If you want to ensure secure communication between your IdP and your Splunk platform instance, you can enable encrypted SAML assertions. When the Splunk platform receives an encrypted assertion from an IdP, it automatically decrypts the assertion and processes the login based on the information in the assertion, provided that you supply a public key to the IdP and enable encrypted assertions on the IdP.
You can configure automatic decryption of SAML assertions using the default server certificate only. Currently, there is no support for this option with other certificates.
- Open a shell or command prompt.
- On your Splunk platform instance, change to the
- Export the public key from the default server certificate using the
$SPLUNK_HOME/bin/splunk cmd openssl x509 -outform der -in server.pem -out publicKey.crt
- Using the configuration interface of your IdP, enable encrypted assertions on your IdP.
This setup differs based on the IdP you use. Some IdPs might not support encrypted assertions.
- Using the configuration interface of your IdP, upload the publicKey.crt file to your IdP
- Follow the instructions earlier in this topic to configure the Splunk platform to authenticate using your IdP.
- Log into the Splunk platform with a user on your IdP. If login succeeds, you have configured SAML assertion correctly.
User experience when logging into a Splunk instance configured with RSA multifactor authentication
Configure SSO with PingIdentity as your SAML identity provider
This documentation applies to the following versions of Splunk® Enterprise: 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.2.0, 8.2.1