Splunk

Splunk offers both IdP-initiated SAML SSO (for SSO access through the Admin Portal) and SP-initiated SAML SSO (for SSO access directly through the Splunk web application). You can configure Splunk for either or both types of SSO.

Note:   This document is written for Splunk On-Premise 8.1+. If you are not using this version, your interface may differ from the descriptions in this document.

Splunk SSO Requirements

Before you configure the Splunk web application for SSO, you need the following:

  • A registered Privileged Access Service account and at least one Centrify Connector installed on a Windows computer (if you use only the Privileged Access Service directory as your identity store, you do not need to install the Centrify Connector).

  • A running version of Splunk Enterprise.

  • An active Splunk Enterprise account with administrator rights for your organization.

  • Centrify or your Active Directory configured to provide the role, realName, and mail attributes for the SSO user.

  • An admin role with change authentication capability. This permission level lets you enable SAML and edit authentication settings on the Splunk search head.

  • A signed certificate in both the Splunk web application and Centrify Admin Portal. You can either download one from Admin Portal or use your organization’s trusted certificate. If you use your own certificate, upload the signing certificate and its private key in a .pfx or .p12 file to the application settings in Admin Portal, and upload the public key certificate in a .cer or .pem file to the web application.

Note:   Currently Splunk does not support certificate chaining and the certificate provided to Splunk must be publicly verifiable.

  • The Privileged Access Service tenant certificate contains two certificates in chain. If you use the Privileged Access Service tenant certificate for your application and you provide that certificate to Splunk, the application will fail to validate the SAML response. If you use that certificate for your application, you must provide the Centrify CA certificate (the root certificate from the Centrify tenant certificate in Splunk) for the Splunk application to correctly verify the signature.

  • If you have more than two certificates in chain, e.g. Leaf > Intermediate > Root and you provide the Leaf certificate to Splunk, Splunk will fail to validate the SAML response. In this case you must follow the steps explained in this Splunk forum answer:

https://answers.splunk.com/answers/408134/saml-assertion-signature-verification-failed-unabl.html#answer-431017

Adding the Splunk App in Admin Portal

Configuring Splunk SSO

The following steps are specific to the Splunk application and are required in order to enable SSO for Splunk. For information on optional configuration settings available in the Centrify Admin Portal, see Optional configuration settings.

Creating and uploading the Splunk Metadata in Admin Portal

Note:   Uploading the Splunk Metadata file modifies the SAML assertion script. It is recommended that you copy and save your script before uploading the Splunk Metadata file.

Note:   For more information about customizing scripts, see Editing the assertion script.

Mapping SAML groups to Splunk roles

For more information

Splunk Specifications

Each SAML application is different. The following table lists features and functionality specific to Splunk.

Capability

Supported?

Support details

Web browser client

Yes

 

Mobile client

No

 

SAML 2.0

Yes

 

SP-initiated SSO

Yes

 

IdP-initiated SSO

Yes

 

Force user login via SSO only

Yes

After SSO is enabled, standard login forces users to login with SSO. To bypass SSO, login with this URL: https://<YOUR-SPLUNK-FQDN:PORT>/account/login?loginType=Splunk

Separate administrator login
after SSO is enabled

Yes

Administrators can login separately using the SSO bypass URL: https://<YOUR-SPLUNK-FQDN:PORT>/account/login?loginType=Splunk

User or Administrator account lockout risk

No

After SAML is enabled, users can still login using the SSO bypass URL: https://<YOUR-SPLUNK-FQDN:PORT>/account/login?loginType=Splunk

Note: After SAML is enabled, users without SAML-enabled accounts (user-password only) can only login with the bypass URL.

Automatic user provisioning

Yes

User is created in Splunk after successful consumption of SAML assertion.

Multiple User types

Yes

Admin

User

Self-service password

Yes

Users can reset their own passwords only if they are non-provisioned users and have the change_own_password capability.

App Gateway

Yes

The App Gateway can be used to securely access this application outside of your corporate network. See Configuring an application to use the App Gateway for more information.

Note: The App Gateway is a premium feature and is available only in the Privileged Access Service App+ Edition. Please contact your Privileged Access Service representative to have the feature enabled for your account.

Access restriction using a corporate IP range

Yes

You can specify an IP Range in the Admin Portal Policy page to restrict access to the application.

Splunk script

The following script is the original Splunk script provided in Admin Portal. Copying and pasting this script to the Advanced page in Admin Portal will return the script to its original “factory installed” state:

setIssuer(Issuer);
setSubjectName(UserIdentifier);
setAudience('splunkEntityId');
setRecipient(ServiceUrl);
setHttpDestination(ServiceUrl);
setSignatureType('Response');
setNameFormat('persistent');
if (ServiceUrl.match(/YOUR-SPLUNK-FQDN-AND-PORT/)) {
  throw '_I18N_Exception_AcsUrlNotCompletelyConfigured';
}
var displayName = LoginUser.DisplayName;
if (!displayName) {
  throw '_I18N_Exception_BadSamlAttributeValue';
}
var allRoles = new Array();
var groupNames = LoginUser.GroupNames;
for (var i = 0; i < groupNames.Length; i++) {
  allRoles.push(groupNames[i]);
}
var cloudRoles = LoginUser.RoleNames;
for (var i = 0; i < cloudRoles.Length; i++) {
  allRoles.push(cloudRoles[i]);
}
setAttributeArray('role', allRoles);
setAttribute('displayname', displayName);
setAttribute('emailaddress', UserIdentifier);