Integrate an Identity Provider with Splunk Cloud Services for authentication and authorization

Splunk supports the use of an identity provider (IdP) of your choosing to perform single sign-on (SSO) authentication and authorization functions for access to Splunk Cloud Services (SCS) resources. Splunk provides this support through the Security Assertion Markup Language (SAML) version 2.0 protocol.

Because each identity provider has its own way of accepting inbound communication for authentication and authorizing of users, SCS cannot communicate with identity providers natively. SCS can use the SAML protocol to communicate with IdPs that also use SAML.

You can connect SCS to your IdP using the Splunk Cloud Console and the configuration website for the IdP you use. Each IdP has a certain procedure to enable an application through which SCS connects to perform authentication and authorization.

While this site provides some instruction around configuring your IdP to enable a SAML application, the documentation for your IdP is always the best place to get the latest IdP configuration information.

Turn on just-in-time provisioning to join users to your tenant automatically

As part of integrating SCS to an IdP, you can enable what is known as just-in-time (JIT) provisioning for your tenant. JIT provisioning lets you automatically bring users from your Identity Provider into your tenant when they first log in. When JIT provisioning is active, Splunk Cloud Services assigns users to the groups that you specify in the JIT Provisioning section of the IdP integration page. You won't have to manually invite them to the tenant for them to access it.

As JIT is a method of provisioning access rather than an invitation, users won't receive an email when you enable JIT provisioning. They instead will receive access based on the groups you assign to them in the JIT provisioning section.

You do not have to turn on JIT provisioning to invite users to your tenant, but you do have to configure an IdP to SCS for JIT provisioning to work. See "Enable JIT provisioning" later in this topic for instructions.

Configure an integration between SCS and your identity provider

Splunk supports integration of Splunk Cloud Services with most SAML identity providers that are currently available on the market through the SAML version 2.0 protocol.

A list of procedures to configure the most commonly-used IdPs follows. It is not a comprehensive list of IdP support. While these procedures are IdP-specific, you can perform similar steps for your IdP if it supports the SAML version 2.0 protocol.

• Microsoft Azure Active Directory
• Okta

Enable JIT provisioning

During integration, or after you integrate your IdP with Splunk Cloud Services, you can enable JIT provisioning so that users who log into Splunk Cloud Services the first time get access to your tenant immediately..

You must have already configured an IdP for this feature to work. The feature adds the user to the groups that you specify in the JIT provisioning section of the SAML Configuration page.

1. Log into Splunk Cloud Services as an administrator of your tenant, if you have not already.
2. In the Splunk Cloud Console system bar, click the button with three dots, then click Settings.
3. Click the SAML Configuration tab.
4. Complete the IdP configuration in the 2. Splunk SAML Configuration section, if you have not already.
5. In the 3. JIT Provisioning section, click the button next to Disabled. The text changes to Enabled and the Available groups and Assigned groups list boxes appear.
6. (Optional) You can filter out groups by typing text into the Filter Groups field in the "Available groups" list box to show groups whose names contain the text you enter.
7. In the Available groups list box, choose the groups from the list that you want users to be members of in your tenant immediately after they log in. The groups you choose move to the Selected groups list box.
8. If you have already entered your IdP configuration in the 2. Splunk SAML Configuration section, click the Enable configuration button. Otherwise, click Save to save the JIT provisioning information and any other IdP configuration information you might have entered so far.

Troubleshoot common problems that occur with IdP integration

If you encounter problems with integrating your SAML IdP with Splunk Cloud Services, you can do the following to circumvent these problems.

Sign the SAML document and not the SAML assertion within the document

When you configure the SAML client on the IDP, there is usually an option to either digitally sign an entire SAML document or just the assertion portion of the SAML document. As a client, SCS expects the IdP to sign the whole SAML document. If the IdP only assigns the assertion portion instead of the entire document, identity federation, which is the process in which Splunk Cloud Services and the IdP establish trust for authentication and authorization, fails.

Do not force the SAML client to sign incoming SAML requests

When you configure a SAML client on the IdP, the IdP usually gives you the option to force clients to sign incoming SAML requests. As a SAML client, SCS does not sign SAML requests that it sends. If your IdP requires SAML requests be signed, federation fails.

Do not encrypt the SAML document or the SAML assertion

When you configure a SAML client on the IdP, the IdP usually gives you the option to encrypt the SAML document or the assertion within the document. As a client, SCS expects to receive unencrypted SAML assertions. Federation with SCS fails if the IdP sends an encrypted SAML document or assertion to SCS because SCS does not attempt any decryption of those items.

Use HTTP POST protocol bindings for SAML assertions

When you configure a SAML client on the IdP, the IdP usually gives you the option to send a SAML assertion back to the client using either an HTTP POST or HTTP Redirect protocol binding. As a client, SCS only supports the HTTP POST protocol binding. Federation with SCS fails if the IdP sends SAML assertions using the HTTP Redirect protocol binding because SCS does not support this method of receiving assertions.

Export the email address property inside the SAML assertion

When you configure a SAML client on the IdP, you must map the email address of users into a SAML assertion. Federation with SCS fails if it cannot find an email address in SAML assertions that it receives.