Configuring PingIdentity PingFederate (Ping) Security Assertion Markup Language (SAML) Single Sign On (SSO) with Splunk Cloud

preno_passwordsThere are now a few blog postings on SAML configurations for Splunk> Cloud. For Okta , Azure and ADFS. Ping is similar in complexity to the Identity Provider (IdP) ADFS, and can be a bit tricky depending on your implementation. The intent of this guide is help you along on your way to integrate Splunk> Cloud with PingFederate.

My role is a Cloud Services Advisory Engineer on the Customer Adoption and Success Team (CAST) within Splunk>. My focus is to assist our customers in their experience with our Cloud service for Splunk>. With our 6.4.x version of Splunk> Cloud, which this posting is about, the configuration for SAML definitely works quite well, but is not the most user friendly to configure. As well, which we will get into later, if you choose to sign your SAML Authorization Requests and Responses, and you have a certificate within Ping that is signed by a 3rd party Certificate Authority (CA) such as Verisign, GeoTrust, GoDaddy, etc., then you will require the assistance of Splunk> Cloud Operations (Ops) in order to have your certificates put into place on your search head(s).

So let’s get started!

Who do you need?PingFederate

  1. An administrator for your Ping environment.
  2. An administrator for your local Identity Management system (Active Directory, LDAP)
  3. An administrator for your Splunk> Cloud instance. If they’re all the same person (you), you’re in luck. Otherwise you’ll have to run the calendar dice and find time for you all to discuss SAML integration, put in change control, scheduled a time to implement, etc.
  4. Splunk> Ops (if you have a 3rd party signed CA or need any customization assistance in your Ping environment 

Ping Integration:

The following steps were documented within Splunk> Cloud 6.1511.1 of Splunk> Cloud. Ping is supported under version 6.3.1511.0 and higher of Splunk> Cloud.

As well, the version of PingFederate within the screen captures is version It’s a bit dated, as I believe version 8.0 for PingFederate is currently the latest. That being said, the steps, content and screen shots should provide adequate information for a decently knowledgeable Ping admin to set up the necessary config on the IdP side.

    Screen Shot 2016-09-01 at 9.36.26 AM
  1. First have your Splunk> Cloud administrator log into your instance as a user with the ‘admin‘ role.
    If you have multiple search heads in your Splunk> Cloud environment (aka a general search head at ‘https://<acme> and/or possibly an Enterprise Security search head at https://<es-acme> you will need to perform a separate Ping integration for each search head independently.
  2. Confirm that your instance is at version 6.3.1511.0 or later by going to the top menu option ‘Support & Services‘ -> ‘About
  3. Obtain your search head’s metadata.
    This can be obtained by, once logged into a session as an admin role user, entering the URL https://<acme> into your browser’s URL field.
    Something similar will be presented in your browser window:Screen Shot 2016-09-01 at 9.44.54 AM
    Save the metadata file into an XML file. You can either copy/paste the entire page into a text editor (such as Notepad) that does not format the text, or you can simply do a browser File->Save As action and save the page as an <filename>.xml file. It is very important that the file be straight text with no formatting or it will not upload into ADFS cleanly.


    From the metadata, capture the search head’s certificate (masked out above, between the XML tags ‘<ds:X509Certificate>‘ and ‘</ds:X509Certificate>‘. Save the certificate into a non-formatted text file (Notepad for example) and place a row above the certificate with the text ‘—–BEGIN CERTIFICATE—–‘ and a row below the certificate with the text ‘—–END CERTIFICATE—–‘. It should look something similar to:

    Screen Shot 2016-09-01 at 10.11.12 AM

  4. Create a Service Provider connection on Ping Federate
  5. Create a new SP connection with “Browser SSO profile” – Protocol SAML 2.0
    Step 5 create new SP connection
  6. Configure the SP Connection Options. Make sure “Attribute Query” is selected.
    Step 6 configure SP connection options
  7. Import the Splunk> metadata file that was acquired from the instance’s https://<acme> in step 3 above.
    Step 7 import metadata
  8. After importing metadata, the “Base URL” may have a port within it (aka ““). If so, remove the port quantifier and make sure the URL just shows something similar to ““.
    We suggest a naming scheme such as “splunk-<companyname>” for the “Entity ID“, however that is up to your preferences. Remember this “Entity ID” as it will be manually typed into the Splunk> SAML configuration as described later in this posting. If you are integrating with more than one search head (such as a general search head and also an Enterprise Security (ES) search head, there will be separate Ping SP Connections for each search head you integrate with. Use an “Entity ID” naming scheme that makes sense.
    Add a “Connection Name” per your preferences, other fields are optional.
    Step 8 base url entity id connection name
  9. Configure SAML profiles. At a minimum, enable SP-Initiated Single Sign On (SSO) and SP-Initiated Single Logout (SLO). Some users of Splunk Cloud have enabled IdP-Initated SSO and SLO as well.
    Step 9 Configure SAML Profiles
  10. Configure “Assertion Creation” -> “Attribute Contract“. Add “role“, “mail” and “realName” attributes.
    The “realName” attribute will be the user’s name displayed in the Splunk GUI. Typically it is best practice to match this to the user’s account name. However some customers like to see a user’s full name, such as ‘Bob Ross’ show up within the UI as the full name. You will need to later work within Ping to configure the value passed through in the ‘realName‘ attribute.
    The “mail” is the user’s e-mail address and will be mapped to the Splunk user’s e-mail address field.
    The “role” attribute is a list of groups the user is assigned to, and will be used to map to Splunk roles in the Splunk Cloud Instance’s SAML configuration.The mapping mechanism will be described in more detail later in this posting.
    The “nameID” in the SAML_SUBJECT will be the username in Splunk.
    Step 10 Configure Attribute Contract
  11. Configure a new adapter (or use existing adapter) instance to authenticate and fulfill the attribute contract.
    Step 11 configure new adapter
  12. Configure “Assertion mapping”
    Step 12 Configure Assertion Mapping
  13. Define a “Data Store” from which you will be pulling user values for the attributes to be passed via SAML.
    Step 13 Define Data Store
  14. Configure the LDAP Directory Search.
    Step 14 configure LDAP directory search
  15. Configure the LDAP filter (depending on your Data Source)
    Step 15 configure LDAP filter
  16. Configure Attribute mapping. Here is where you choose the values that will be passed within the attributes ‘mail‘, ‘realName‘ and ‘role‘.
    Step 16 configure attribute mapping
  17. Configure Assertion Consumer Service (SSO) URL. The “ENDPOINT URL” for your instance will be the URL for the search head (or cluster if you have a search head cluster in Cloud) with ‘/saml/acs‘ appended to it. For our example we use ‘‘.
    Step 17 configure assertion consumer service url
  18. Configure SLO Service URL. The “ENDPOINT URL” will again be your search head’s base URL, then appended with ‘/saml/logout‘. For our example, we use ‘‘.
    Step 18 configure SLO service URL
  19. Configure Allowable SAML Bindings
    Step 19 configure allowable SAML bindings
  20. Configure Signature Policy to sign the requests with certificates.
    Step 20 Configure Signature Policy
  21. Configure Encryption Policy to None. Splunk Cloud> does not support encryption of the SAML conversation. However, all communications are encrypted over SSL via the SSO and SLO endpoints (‘https://…‘)
    Step 21 configure encryption policy
  22. Configure Attribute Query’s Retrievable Attributes, again ‘mail’, ‘realName‘ and ‘role‘.
    Step 22 configure retrievable attributes
  23. Configure the Attribute Source
    Step 23 configure attribute source
  24. Configure Attribute Sources & User Lookup
    Step 24 configure attribute sources user lookup
  25. Configure the LDAP filter
    Step 25 configure LDAP filter
  26. Configure Attribute Mapping Fulfillment
    Step 26 Configure Attribute Mapping Fulfillment
  27. Configure Security Policy to sign the Response, Assertion and Attribute Query.
    Step 27 configure security policy
  28. Configure Back Channel Authentication
    Step 28 Configure Backchannel Authentication
  29. Configure Basic Authentication for SOAP based Attribute Query Request
    Step 29 configure basic authentication
  30. Configure which certificate(& keys ) IDP should be using
    Step 30 Configure IDP certificate
  31. Import Splunk’s certificate that you obtained in step 3 above from the instance’s URL https://<instancename> 31 import Splunk certificate
  32. View Certificate information to make sure it looks good.
    Step 32 View Certificate Information
  33. Select Primary Certificate for Signature Validation
    Step 33 Select Primary Certificate
  34. Activate SP connection (replicate if necessary)
    Step 34 Activate SP Connection
  35. Locate your SP and choose to Export IDP metadata, save this into a file on your desktop to later be imported into your Splunk> Cloud instance.
    Step 35 Export IDP Metadata
  36. Select “Include this certificate’s public key certificate in the <keyinfo> element”.
    Step 36 include public key certificate
  37. Click on “export”. Save to a file on your desktop.
    Step 37 export

Configure Splunk>

  1. On the Splunk instance logged in locally as an Admin user, choose Settings->Access Controls->Authentication Method.  Choose SAML then click on the ‘Configure Splunk to use SAML’ button.
    within the SAML Groups setup page in Splunk, click on the SAML Configuration button in the upper right corner.
  2. The SAML Configuration popup window will appear. Click on Select File to import the XML Metadata file that you saved on your desktop earlier and click Apply.The following fields should be populated by the metadata:
    Single Sign On (SSO) URL
    Single Log Out (SLO) URL
    idP’s Certificate file
    Sign AuthnRequest (checked)
    Sign SAML response (checked)
    Enter in the Entity ID, for our example we used ‘splunk-acme‘ as was used in previous sections within step 8 of the IdP configuration (above).saml_config
    NOTE: If you set signing of the Auth Requests and Responses as stated above in the Ping configuration, you must also enable the check boxes to ‘Sign AuthRequest‘ and ‘Sign SAML response‘. One way to just test if SAML is working without any certificates in the mix is to disable signing of Requests and Responses on both the Ping side and the Splunk> side. Then once you have the overall SAML authentication working, with the proper NameID and all attributes flowing as you expect, then later enable signing of the Requests and Responses. This is especially helpful when 3rd party signed certificates are in the mix. First get SAML working, then have Splunk> Ops put the certificate chain (requires some actions at the CLI on your behalf) into place on the search head(s) and then enable Request and Response signing on both Ping and Splunk>.
  3. Scroll down to the ‘Advanced Settings‘ section.
    Enter in the Fully Qualified Domain Name (FQDN) of the Splunk Cloud instance – ‘https://<customername>
    Enter a ‘0‘ (zero) for the Redirect port – load balancer’s port.
    Click Save to Save the configuration:advanced_2
  4. The next step is set up the SAML groups. Within the Splunk ‘Settings->Access Controls->Authentication Method->SAML Settings‘ page, click the green “New Group” button
  5. Enter in a group name that associates with the passed group names, some examples follow
  6. Test the Ping SAML configuration. Log into the environment through a clean browser session or an incognito browser session.NOTE: If you need to bypass Ping authentication re-direct and get to the local Splunk user/pass auth screen, use the customer’s URL: https://<customer>
  7. Also test logging out of Splunk, you should be re-directed to the Splunk SAML logout page as shown below:

Philip Greer

Posted by