preThere 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!
- An administrator for your Ping environment.
- An administrator for your local Identity Management system (Active Directory, LDAP)
- 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.
- Splunk> Ops (if you have a 3rd party signed CA or need any customization assistance in your Ping environment
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 220.127.116.11. 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.
- 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>.splunkcloud.com and/or possibly an Enterprise Security search head at https://<es-acme>.splunkcloud.com) you will need to perform a separate Ping integration for each search head independently.
- Confirm that your instance is at version 6.3.1511.0 or later by going to the top menu option ‘Support & Services‘ -> ‘About
- 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>.splunkcloud.com/saml/spmetadata into your browser’s URL field.
Something similar will be presented in your browser window:
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:
- Create a Service Provider connection on Ping Federate
- Create a new SP connection with “Browser SSO profile” – Protocol SAML 2.0
- Configure the SP Connection Options. Make sure “Attribute Query” is selected.
- Import the Splunk> metadata file that was acquired from the instance’s https://<acme>.splunkcloud.com/saml/spmetadata in step 3 above.
- After importing metadata, the “Base URL” may have a port within it (aka “https://acme.splunkcloud.com:8000“). If so, remove the port quantifier and make sure the URL just shows something similar to “https://acme.splunkcloud.com“.
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.
- 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.
- 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.
- Configure a new adapter (or use existing adapter) instance to authenticate and fulfill the attribute contract.
- Configure “Assertion mapping”
- Define a “Data Store” from which you will be pulling user values for the attributes to be passed via SAML.
- Configure the LDAP Directory Search.
- Configure the LDAP filter (depending on your Data Source)
- Configure Attribute mapping. Here is where you choose the values that will be passed within the attributes ‘mail‘, ‘realName‘ and ‘role‘.
- 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 ‘https://acme.splunkcloud.com/saml/acs‘.
- 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 ‘https://acme.splunkcloud.com/saml/logout‘.
- Configure Allowable SAML Bindings
- Configure Signature Policy to sign the requests with certificates.
- 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://…‘)
- Configure Attribute Query’s Retrievable Attributes, again ‘mail’, ‘realName‘ and ‘role‘.
- Configure the Attribute Source
- Configure Attribute Sources & User Lookup
- Configure the LDAP filter
- Configure Attribute Mapping Fulfillment
- Configure Security Policy to sign the Response, Assertion and Attribute Query.
- Configure Back Channel Authentication
- Configure Basic Authentication for SOAP based Attribute Query Request
- Configure which certificate(& keys ) IDP should be using
- Import Splunk’s certificate that you obtained in step 3 above from the instance’s URL https://<instancename>.splunkcloud.com/saml/spmetadata
- View Certificate information to make sure it looks good.
- Select Primary Certificate for Signature Validation
- Activate SP connection (replicate if necessary)
- 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.
- Select “Include this certificate’s public key certificate in the <keyinfo> element”.
- Click on “export”. Save to a file on your desktop.
- 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.
- 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).
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>.
- Scroll down to the ‘Advanced Settings‘ section.
Enter in the Fully Qualified Domain Name (FQDN) of the Splunk Cloud instance – ‘https://<customername>.splunkcloud.com
Enter a ‘0‘ (zero) for the Redirect port – load balancer’s port.
Click Save to Save the configuration:
- 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
- Enter in a group name that associates with the passed group names, some examples follow
- 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>.splunkcloud.com/en-US/account/login?loginType=splunk
- Also test logging out of Splunk, you should be re-directed to the Splunk SAML logout page as shown below: