Docs » Configure SSO integrations

Configure SSO integrations 🔗

Splunk Observability Cloud provides SSO login service integrations that let your users log in using a third-party identity provider (IdP) that uses SAML SSO. Observability Cloud supports SSO initiated by the IdP. Observability Cloud also supports SSO initiated by Observability Cloud, and this option lets your users log in to Infrastructure Monitoring using a custom URL you specify.

Observability Cloud supports the following SSO integrations:

Note about realms

A realm is a self-contained deployment of Splunk Observability Cloud in which your organization is hosted. Different realms have different API endpoints. For example, the endpoint for sending data in the us1 realm is https://ingest.us1.signalfx.com, while the endpoint for sending data in the eu0 realm is https://ingest.eu0.signalfx.com.

When you see a placeholder realm name in the documentation, such as <YOUR_REALM>, replace it with your actual realm name. To find your realm name, open the application navigation menu, select your name, select Account Settings, and see the Realm field. If you don’t include the realm name when specifying an endpoint, Observability Cloud defaults to the us0 realm.

Provide a custom URL for accessing Observability Cloud 🔗

A custom URL is required to allow users to log in to Observability Cloud from your organization’s login page. If no custom URL is provided, users can still log in through the identity provider to access Observability Cloud.

When you configure a login service integration and select Show on login page, the login details for the service appear on your organization’s login page. You can have multiple SSO logins.

To allow users to log in to Observability Cloud using a custom URL, such as your_org.example.com, send a request to observability-support@splunk.com. Include the URL you want in your request.

Name an SSO integration 🔗

Give your login service integration a name that your users recognize. On your custom login page, this name appears in the button your users select to sign in. For example, use the name “Log in with Okta” for an Okta login service integration.

Integrate an identity provider with multiple organizations 🔗

When you integrate a login service with Observability Cloud, you need to provide information about the integration to the login service. Infrastructure Monitoring gives you an entity identifier (entity ID) that you provide when you configure the login service itself. The service uses the entity ID and other information to connect with Observability Cloud.

For multiple organizations, the login service needs an entity ID and other information for each organization. Observability Cloud can provide you with an integration-specific entity ID for the integration in each organization.

When you configure the login service, you provide the entity ID along with other information for each organization you want the login service to connect with. The steps for integrating with each supported login service include the optional steps for using integration-specific entity IDs.

The Google SSO integration doesn’t support integration-specific entity IDs.

Note

You only need an integration-specific entity ID if you want to use the same IdP for multiple organizations.

General integration-specific entity ID steps 🔗

To get an integration-specific entity ID for an integration, do the following when you create the integration:

  1. Access Splunk Observability Cloud.

  2. Open the navigation Menu.

  3. Select Data Setup to open the Connect Your Data page.

  4. In the Login Services section, click the tile for the login service integration you want.

  5. Click New Integration.

  6. Select the Integration-specific Entity ID option. Next to this option, the entity ID displays in the form of a URI. Copy this URI and provide it when you configure the login service to communicate with Observability Cloud.

Configure an ADFS SSO integration 🔗

The Microsoft Active Directory Federation Services (ADFS) SSO integration lets your users log in to Observability Cloud using your Microsoft ADFS portal.

Before you proceed, review the section Name an SSO integration to learn about naming your integrations.

This integration is only available for Microsoft Active Directory with ADFS. In addition, you need to have the following fields in your ADFS configuration:

  • First Name

  • Last Name

  • Email

The procedure for configuring ADFS with Observability Cloud has these sections:

Send your domain information to Splunk Support 🔗

Your users can’t authenticate using an ADFS SSO integration until Splunk activates it. To request the activation, have an organization administrator send your login email domain to observability-support@splunk.com. For example, if your users log in to SSO with user IDs like kai@example.com, then example.com is the login email domain to send to observability-support@splunk.com.

After Splunk Support activates the integration, users can authenticate using ADFS SSO.

Create a new ADFS SSO integration in Observability Cloud 🔗

To create a new ADFS integration in Observability Cloud:

  1. Access Splunk Observability Cloud.

  2. Open the navigation Menu.

  3. Select Data Setup to open the Connect Your Data page.

  4. In the Login Services section, click the Active Directory FS tile to display the Active Directory FS page.

  5. Click New Integration.

  6. In the Name field, enter a name for your ADFS SSO integration.

  7. Save the Integration ID field value to a file. You’ll need this value in a subsequent step.

  8. If you want to set up ADFS to integrate with multiple organizations:
    1. Select Integration-specific Entity ID.

    2. Save the URI displayed next to the check box. You’ll need it in a subsequent step to configure ADFS. To learn more, see Integrate an identity provider with multiple organizations.

  9. Keep this page open. You’ll upload the Certificate and Metadata files in a subsequent step.

Add Observability Cloud to ADFS 🔗

Add Observability Cloud as a relying party in ADFS:

  1. In separate browser tab or window, log in to the ADFS server and open the ADFS management console.

  2. In the console, right-click on Relying Party Trusts, select Add Relying Party Trust, then click Start.

  3. Select Claims aware, then click Next.

  4. Select Enter data about the relying party manually, then click Next.

  5. For Display name, enter Splunk Observability Cloud, then click Next.

  6. On the screen that appears, leave the default certificate settings unchanged.

  7. On the Configure URL page, leave the two options deselected and click Next.

  8. On the Configure Identifiers page, enter your entity ID in the Relying party trust identifiers text box:

    • If you’re setting up multiple integrations for ADFS, enter the integration-specific entity ID you obtained previously.

    • If you’re using a single integration for ADFS, enter one of these entity IDs, depending on the realm you’re in:

      • If your organization uses realm us0, enter the following:

        https://api.signalfx.com/v1/saml/metadata

      • If your organization uses another realm, enter the following:

        https://api.<YOUR_REALM>.signalfx.com/v1/saml/metadata

      To learn more about realms, see Note about realms.

  9. Click Add, then click Next.

  10. The next step in the wizard lets you configure multi-factor authentication. Because Observability Cloud doesn’t require this option, click Next.

  11. On the Choose access control policy page, do the following:

    1. Select Permit everyone.

    2. Optionally, you can select I do not want to configure access control policies at this time In a later step, you can add authorization rules. Adding rules isn’t part of the integration procedure, so it’s not described here.

    3. Click Next.

  12. Review your settings, and then click Next.

  13. On the Ready to Add Trust page, click Next.

  14. On the Finish page, deselect Configure claims issuance policy for this application, then click Close.

  15. On the page that appears, select Relying Party Trusts, right-click Splunk Observability Cloud, then select Properties.

  16. Click the Advanced tab, then from the Secure Hash Algorithm drop-down list, select SHA-1.

  17. Click the Endpoints tab, then click Add SAML… In the dialog box, do the following:

    • From the Endpoint type drop-down list, select SAML Assertion Consumer.

    • From the Binding drop-down list, select POST.

    • Select Set the trusted URL as default.

    • For Trusted URL, enter the URL, replacing <INTEGRATION_ID> with the integration ID you copied in step 3 of the section Create a new ADFS SSO integration in Observability Cloud:

      • If your organization is in realm us0, enter the following:

        https://api.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

      • If your organization is in another realm, enter the following:

        https://api.<YOUR_REALM>.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

      To learn more about realms, see Note about realms.

  18. Click OK to close the Add an endpoint dialog box.

  19. Click OK to close the Splunk Observability Cloud Properties dialog box.

  20. On the page that appears, select Relying Party Trusts and right-click on Splunk Observability Cloud.

  21. From the Claim rule policy drop-down list, select Edit Claim Issuance Policy….

  22. Select Add Rule..

  23. Select Send LDAP Attributes as Claims, and then click Next.

  24. Enter a name for the claim rule, such as “LDAP”, then from the Attribute store drop-down list, select Active Directory.

  25. In the Mapping of LDAP attributes to outgoing claim types pane, use the drop-down lists to set the mappings between the LDAP Attribute and Outgoing Claim Type columns:

    • E-Mail-Addresses (email address LDAP attribute): User.email

    • Given-Name (First Name LDAP attribute): User.FirstName

    • Surname (Last Name LDAP attribute): User.LastName

    • SAM-Account-Name (unique user identifier LDAP attribute): PersonImmutableID.

  26. Select Add rule… again, then select Transform an incoming claim.

  27. Enter a name for the claim rule, such as “Email to name ID”.

  28. Configure this rule to pass through Name ID, if it’s not already provided by your ADFS or SAML implementation.

    For example, if you want to pass through User.email as the Name ID, do the following:

    1. From the Incoming claim type drop-down list, select User.email.

    2. From the Outgoing claim type drop-down list, select Name ID.

    3. Regardless of the types you choose, from the Outgoing name ID format drop-down list, select Persistent Identifier.

    4. Click Finish.

Obtain ADFS certificate to install to Observability Cloud 🔗

Obtain an ADFS certificate to install to Observability Cloud:

  1. In the ADFS management console, select Service, then select Certificates.

  2. From the Token-signing list, right-click the certificate, then select View Certificate.

  3. Select Detail, then click Copy to file. The certificate export wizard appears.

  4. Click Next, then select DER encoded binary X.509.

  5. Enter certificate.cer, then click Finish.

  6. Convert the certificate from a .cer format to a .pem format, using the openssl tool:

    openssl x509 -inform der -in certificate.cer -out certificate.pem

    In a following step, you upload this file to Observability Cloud.

Obtain federation metadata file to install to Observability Cloud 🔗

Obtain a federation metadata file to install to Observability Cloud:

  1. In the ADFS management console, navigate to Endpoints.

  2. Locate the Federation Metadata endpoint and copy the URL that appears. It’s similar to the following:

    https://<YOUR_SERVER_IP>/FederationMetadata/2007-06/FederationMetadata.xml.

  3. Open a new browser window or tab, then navigate to the URL you copied. This opens a file download dialog box.

  4. Save the file FederationMetadata.xml. In a following step, you upload this file to Observability Cloud.

Upload the ADFS certificate and federation metadata to Observability Cloud 🔗

In Observability Cloud, do the following:

  1. Find the Active Directory FS page you opened in a previous step.

  2. Click the Upload File link in the Certificate field and upload the certificate.pem file.

  3. Click the Upload File link in the Metadata field and upload the FederationMetadata.xml file.

  4. Click Save.

The Microsoft ADFS SSO integration is now available to users in your ADFS organization. When users sign in to Observability Cloud from ADFS for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

Note

The ADFS portal is the only way that your users can log in to Observability Cloud.

Configure an Azure Active Directory (Azure AD) SSO integration 🔗

The Microsoft Azure Active Directory (Azure AD) integration lets users log in to Observability Cloud using their Azure AD account.

Before you proceed, review the section Name an SSO integration to learn about naming your integrations.

To configure an Azure AD SSO integration, you must be an administrator for your organization. To learn more, see Grant and revoke administrative access.

Note

The procedure for creating multiple integrations for Azure AD is different from the procedure for creating a single integration.

Configure Azure AD for a single organization 🔗

For instructions, see “Tutorial: Azure Active Directory single sign-on (SSO) integration with SignalFx” on the Microsoft documentation website.

Configure Azure AD for multiple organizations 🔗

  1. In a new browser tab or window, access “Tutorial: Azure Active Directory single sign-on (SSO) integration with SignalFx,” provided on the Microsoft documentation website.

  2. Follow the instructions until you reach step 7 in the section Step 2: Begin SignalFx SSO configuration.

  3. After you complete step 7, do the following:

    1. In the Azure AD integration tile, select Integration-specific Entity ID.

    2. Copy the URI that appears next to check box, so you can use it in steps 4a and 4b of the section Step 3: Configure Azure AD SSO.

  4. When you reach step 4a and 4b of Step 3: Configure Azure AD SSO, use the integration-specific entity ID you copied from Observability Cloud instead of the URLs listed in the instructions.

  5. Proceed with the rest of the instructions.

After you complete these steps, the Azure AD SSO integration is available to users in your Azure AD organization. When users sign in to Observability Cloud from Azure AD for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

Configure a Google SSO integration 🔗

Note

The Google SSO integration doesn’t support integration-specific entity IDs.

The Google SSO integration lets users in your Google domain log in to the application using their Google credentials.

Before you proceed, review the section Name an SSO integration to learn about naming your integrations.

To configure a Google SSO integration, you must be an administrator for your organization. To learn more, see Grant and revoke administrative access.

Note

When you configure the Google SSO integration for a domain, everyone in the domain has access to the organization, even if they have not yet been added as an organization user.

  1. Access Splunk Observability Cloud.

  2. Open the navigation Menu.

  3. Select Data Setup to open the Connect Your Data page.

  4. In the Login Services section, click the Google Sign-In tile to display the Google Sign-In page.

  5. To add Google SSO for a new domain, click Add Domain.

  6. A Google dialog box appears. Select the email address associated with the Google domain that you want to add. For example, if you select the Google account myAddress@myGoogleDomain.com, you add myGoogleDomain.com as the authenticated domain for logging in.

  7. Exit the dialog box. The domain appears in the list of domains for the Google SSO integration. Anyone who has credentials for that domain can use them to log in to Observability Cloud.

If at least one Google domain has access to your organization, the option to sign in with Google appears on the Observability Cloud login screen. If your organization has a custom URL, the option to sign in with Google also appears on the custom URL login page.

To remove a Google domain’s login access, click the Google Sign-In tile on the Data Setup page and click the “x” to the right of the domain name.

Configure a Google Cloud Identity SSO integration 🔗

The Google Cloud Identity (GCI) SSO integration lets users log in to Observability Cloud using their Google Cloud credentials.

Before you proceed, review the section Name an SSO integration to learn about naming your integration.

To configure GCI as an IdP using an Observability Cloud SSO integration, you must be an administrator for your organization and a super-administrator of your Google domain. To learn more, see Grant and revoke administrative access.

The G Suite Administrator Help document topic, developed by Google, describes how to configure the integration.

After you complete these steps, the GCI SSO integration is available to users in your GCI organization. When users sign in to Observability Cloud from GCI for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

Configure an Okta SSO integration 🔗

The Okta SSO integration lets your users log in to Observability Cloud using Okta.

Before you start, review the section Name an SSO integration to learn about naming your integrations.

Note

To use this procedure, you must be an administrator of your Okta organization and your Observability Cloud organization.

  1. Open a browser tab or window for Observability Cloud, and another for Okta.

  2. Switch to Okta, then follow these steps to add Observability Cloud as an Okta application:

    1. Click Admin, then click Applications

    2. Click Add Application.

    3. In the directory that appears, find for SignalFx, then add it by clicking Add.

  3. Switch to Observability Cloud:

    1. Open the navigation Menu.

    2. Select Data Setup to open the Connect Your Data page.

    3. In the Login Services section, click the Okta tile to display the Okta page.

    4. Click New Integration.

    5. In the Name text box, enter the name for your integration.

    6. Copy the Integration ID value.

    Even if you have multiple organizations that you want to integrate with Okta SSO, leave Integration-specific Entity ID deselected. The Observability Cloud Okta integration provides this automatically for multiple organizations.

  4. Switch to Okta:

    1. Paste the integration ID value into the Integration ID text box, then click Next.

    2. Assign the SignalFx application to users in your Okta organization, then click Next.

    3. Click Sign on, then click View Setup instructions.

    4. Copy the following strings from the instructions, and paste them into a text editor:

      • Public Key

      • Issuer URL

      • Metadata URL

  5. Switch to Observability Cloud:

    1. Copy and paste the Okta Public Key value into the Public Key text box.

    2. Copy and paste the Okta Issuer URL value into the Issuer URL text box.

    3. Copy and paste the Okta Metadata URL value into the Metadata URL text box.

    4. Click Save. The message Validated! appears. If an error appears instead, double-check the values that you copied and pasted. Contact observability-support@splunk.com for help in resolving errors.

The Okta SSO integration is now available to users in your Okta organization. When users sign in to Observability Cloud from Okta for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

Okta SSO authentication and Observability Cloud username/password authentication are independent. Existing Observability Cloud users that you created before enabling the Okta SSO integration can use their Observability Cloud as well as their Okta SSO credentials to log in. Observability Cloud generates a password for users you create in Okta SSO. If the Okta login portal is unavailable, Observability Cloud users can use the reset password link on the Observability Cloud login page to get native Observability Cloud credentials.

Configure a OneLogin SSO integration 🔗

The OneLogin SSO integration lets your users log in to Observability Cloud using OneLogin.

Before you start, review the section Name an SSO integration to learn about naming your integrations.

Note

To use this procedure, you must be an administrator of your OneLogin organization and your Observability Cloud organization.

  1. Open a browser tab or window for Observability Cloud, and another for OneLogin.

  2. In OneLogin, do the following:

    1. Add Observability Cloud by selecting Apps > Add Apps > SignalFx.

    2. In the dialog box, make any changes you want, then click Save.

    3. Select SSO to open the SSO configuration page.

  3. In Observability Cloud:

    1. Open the navigation Menu.

    2. Select Data Setup to open the Connect Your Data page.

    3. In the Login Services section, click the OneLogin tile to display the OneLogin page.

    4. Click New Integration.

    5. In the Name text box, enter the name for your integration.

    6. Copy the Integration ID value.

  4. In OneLogin:

    1. Go to the Configuration tab, then paste the integration ID into the SignalFx ID text box.

    2. Copy the value of the X.509 certificate text box and and save it in a text editor so you can use it in the next steps.

    3. Copy the value of the Issuer URL text box and save it in a text editor so you can use it in the next steps.

  5. In Observability Cloud:

    1. Copy the value of X.509 certificate from the text editor and paste it into the Public Key text box.

    2. Copy the value of Issuer URL from the text editor and paste it into the Issuer URL text box.

    3. Click Save. The message Validated! appears. If an error appears instead, double-check the values that you copied and pasted. Contact observability-support@splunk.com for help in resolving errors.

The OneLogin SSO integration is now available to users in your OneLogin App portal. When users use the integration for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

OneLogin SSO authentication and Observability Cloud username/password authentication are independent. Existing Observability Cloud users that you created before enabling the OneLogin SSO integration can use their Observability Cloud as well as their OneLogin SSO credentials to log in. Observability Cloud generates a password for users you create in the OneLogin SSO integration. If the OneLogin App portal is unavailable, Observability Cloud users can use the reset password link on the Observability Cloud login page to get native Observability Cloud credentials.

Configure a PingOne SSO integration 🔗

The PingOne SSO integration lets your users log in to Observability Cloud using PingOne.

Before you start, review the section Name an SSO integration to learn about naming your integrations.

Note

To use this procedure, you must be an administrator of your PingOne organization and your Observability Cloud organization.

To set up your PingOne SSO integration, follow these steps:

  1. Open a browser tab or window for Observability Cloud, and another for PingOne.

  2. In Observability Cloud, do the following:

    1. Open the navigation Menu.

    2. Select Data Setup to open the Connect Your Data page.

    3. In the Login Services section, click the PingOne tile to display the PingOne page.

    4. Click New Integration.

    5. In the Name text box, enter a name for your PingOne SSO integration.

    6. Copy the value next to Integration ID so you can use it in a later step.

  3. In PingOne, do the following:

    1. Click Applications. A list of your installed applications appears.

    2. Click Add Application, and then select Search Application Catalog.

    3. In the search field, enter SignalFx. Click the SignalFx application.

    4. If the Setup is active, click it. A setup screen appears.

      If the Setup button is disabled, and you see the tooltip “You need to setup a connection first,” then you might need to connect to an Identity Repository. To connect to an Identity Repository:

      1. At the top of the PingOne page, click Setup.

      2. Click Connect to an Identity Repository.

      3. Select the Identity Repository you want to use, click Next twice, then click Finished.

    5. Click SignalFx, then click Setup.

    6. Optional: Copy the configuration parameters to keep as a reference.

    7. Click Continue to Next Step.

    8. In the ACS URL field, a URL appears that’s similar to https://api.signalfx.com/v1/saml/acs/<INTEGRATION_ID>.

    9. Replace <INTEGRATION_ID> with the integration ID you copied in a previous step.

    10. Confirm that the ACS URL and Entity ID URLs refer to your Observability Cloud realm:

      • If your Observability Cloud organization uses the us0 realm, enter the following:

        • ACS URL: https://api.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

        • Entity ID: https://api.signalfx.com/v1/saml/metadata

      • If your Observability Cloud organization uses another realm, enter the following:

        • ACS URL: https://api.<YOUR_REALM>.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

        • Entity ID: https://api.<YOUR_REALM>.signalfx.com/v1/saml/metadata

        To learn more about realms, see Note about realms.

    11. Click Continue to Next Step. The Attribute Mapping screen appears.

    12. For SAML_SUBJECT:

      1. Click Advanced.

      2. In the Name ID Format to send to SP dropdown list, select urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, then click Save.

      3. Select other attributes as needed.

    13. Click Continue to Next Step. The Group Access screen appears.

    14. Select the users who should have access to Observability Cloud. Click Continue to Next Step. The customization screen appears.

    15. Configure the SignalFx application, then click Continue to Next Step. The review screen appears.

    16. In the review screen that appears, do the following:

      1. Locate the Certificate field, then click Download to download the pingone-signing.crt file to your computer.

      2. Locate the SAML Metadata field, and then click the Download link to download the saml2-metadata-idp.xml file to your computer.

      3. Click Finish. The PingOne Applications list appears. In the list, SignalFx appears as an active application.

  4. In Observability Cloud, do the following:

    1. Locate the Certificate text box:

    2. Click Upload File. A file system dialog box opens.

    3. To upload the certificate file, select the pingone-signing.crt file you downloaded in a previous step.

    4. After the upload, the text for Certificate changes to match the uploaded file.

  5. Locate the Metadata text box:

    1. Click Upload File. A file system dialog box opens.

    2. To upload the metadata file, select saml2-metadata-idp.xml file you downloaded in a previous step.

    3. After the upload, the text in the Metadata text box changes to match the uploaded file.

  6. Click Save. Observability Cloud displays a Validated! message.

The PingOne SSO integration is now available to users in your PingOne application. When users use the integration for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

PingOne SSO authentication and Observability Cloud username/password authentication are independent. Existing Observability Cloud users that you created before enabling the PingOne SSO integration can use their Observability Cloud as well as their PingOne SSO credentials to log in. Observability Cloud generates a password for users you create in the PingOne SSO integration. If the PingOne application is unavailable, Observability Cloud users can use the reset password link on the Observability Cloud login page to get native Observability Cloud credentials.

Configure SSO using a generic SAML SSO integration 🔗

If you use an SSO login service other than the ones listed previously, you can create a generic SAML SSO integration for your organization. (If you already have a SAML SSO integration for your organization, follow the steps in Install a generic SAML SSO integration to install it in Observability Cloud.)

Generic SAML SSO integrations 🔗

Observability Cloud provides integrations for specific SAML SSO providers. If your provider isn’t in the list of supported integrations, your organization administrator can request a generic integration from Observability Cloud. You can use this integration to test and develop a SAML SSO provider. Using this integration, administrators can direct Observability Cloud to use any publicly-available SSO endpoint to authenticate users.

To enable the generic SAML SSO integration, your account administrator needs to send an email to the Support team (observability-support@splunk.com). The email must include the domain for the ID/email address that your users provide when they log in. The domain is the part of the user ID/email address string that followings the @ sign.

Information required for generic SAML SSO integrations 🔗

  • One of:

    • User.FirstName and User.LastName: User’s first and last name

    • User.FullName: User’s full name

  • User.email: User’s email address

  • PersonImmutableID: A unique identifier for this user

  • ACS URL

    Some ACS URLs include realm information. To learn more, see Note about realms.

    The ACS URL includes an integration ID that’s unique for each integration. The SAML page displays this ID.

    The URL has one of the following formats:

    • If your organization uses the us0 realm:

      https://api.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

    • If your organization uses a realm other than us0:

      https://api.<YOUR_REALM>.signalfx.com/v1/saml/acs/<INTEGRATION_ID>

  • Entity ID

    • If you have a single organization, enter the following entity ID:

      • If your organization uses the us0 realm, enter the following:

        https://api.signalfx.com/v1/saml/metadata/<ENTITY-ID>

      • If your organization uses a realm other than us0, enter the following:

        https://api.<YOUR_REALM>.signalfx.com/v1/saml/metadata<ENTITY-ID>

      <ENTITY-ID> is the entity ID displayed when you start creating a new integration.

    • If you have multiple organizations that you want to integrate with a single IdP, do the following:

      1. In the New Integration pane, select Integration-specific Entity ID. Next to the option, the integration-specific entity ID appears in the form of a URI.

      2. Copy the entity ID and provide it when you configure the login service to communicate with Observability Cloud.

  • Assertion Signature

    The SSO provider must put the assertion signature in the assertion message, not in the request itself.

  • RelayState

    Observability Cloud sends a dynamic RelayState, so the SSO provider must accept and pass back the dynamic RelayState.

Install a generic SAML SSO integration 🔗

This section describes how to install a generic SAML SSO integration that your organization has implemented.

Prerequisites 🔗

Before you start an installation, you need the following information:

  • Name: Descriptive name that appears in the Generic SAML SSO tile

  • Public key: The SAML provider’s public key

  • Issuer URL: The issuer URL provided by the SSO provider

  • One of the following:

    • A publicly-accessible metadata URL provided by the SSO provider

    • Metadata for the SSO provider in XML format. The entity ID that the provider sends as part of the metadata must match the issuer URL.

  • If you have multiple email domains for users in a single Splunk Observability cloud organization, for example, kai@example.com and deepu@examplehq.com, contact observability-support@splunk.com to whitelist multiple domains.

Steps 🔗

To install a generic SAML SSO integration, follow these steps:

  1. Access Splunk Observability Cloud.

  2. Open the navigation Menu.

  3. Select Data Setup to open the Connect Your Data page.

  4. In the Login Services section, click the SAML tile to display the SAML page.

  5. Click New Integration. A dialog box with fields appears.

  6. In the Name field, enter the name for this integration. If your organization has a custom URL, this name appears as the text for the button users click to sign in (see the section Name an SSO integration).

  7. In the remaining fields, enter the information you gathered in the Prerequisites section.

  8. Click Save. The message Validated! appears.

The generic SSO integration is now available to users of the SSO provider. When users use the integration for the first time, they receive an email containing a link that they must open in order to authenticate. This only occurs the first time the user signs in. Subsequent login attempts don’t require validation.

If you want to turn off the email authentication feature, send a request to observability-support@splunk.com.

Generic SSO authentication and Observability Cloud username/password authentication are independent. Existing Observability Cloud users that you created before enabling the generic SSO integration can use their Observability Cloud as well as their SSO credentials to log in. Observability Cloud generates a password for users you create in the generic SSO integration. If the SSO application is unavailable, Observability Cloud users can use the reset password link on the Observability Cloud login page to get native Observability Cloud credentials.

Important

This integration can send credential information to unverified destinations. Although you can use generic SAML SSO integrations to authenticate users, Observability Cloud doesn’t support these integrations as your primary authentication mechanism. The Observability Cloud support team can’t help you diagnose or repair problems you encounter while trying to authenticate users using generic SSO integrations, aside from ensuring that the integration itself is working