Skip to main content
Sumo Logic

Set Up SAML for Single Sign-On

Organizations with Enterprise accounts can provision Security Assertion Markup Language (SAML) 2.0 to enable Single Sign-On (SSO) for user access to Sumo Logic.

In addition to basic SAML configuration, you can choose optional on-demand user creation (using SAML 2.0 assertions), and designate custom login and/or logout portals.

SAML provisioning process

The provisioning process works as follows:

  1. Identify the service provider you will use for SSO. For example:
  2. Configure SAML parameters in Sumo Logic.
  3. Configure service provider settings for Sumo Logic in the SSO system, and verify that any additional Role-Based Access Control (RBAC) roles and groups are set up.
  4. When provisioning is complete, users attempting to access Sumo Logic will be authenticated through the SSO system.


This section has key information about SAML in Sumo.

All SAML integrations on the same Sumo deployment share the same EntityID

All SAML integrations on the same Sumo deployment send SP-initiated authentication requests with the same EntityID. This can pose issues if your IdP expects all integrations to connect to the same authentication URL. Specifically:

  • Your IdP might not let you configure more than one SAML integration because it requires each EntityID to be unique.
  • If your IdP does allow you to configure an additional integration, the IdP will not be able to determine which integration to use when it receives an AuthnRequest message with the common EntityID. In that case, the IdP would typically use the first integration, resulting in SAML logins failures for the additional integrations.

To avoid these issues, if your IdP expects all integrations to connect to the same authentication URL, we recommend that you use IdP-initiated SSO (rather than SP-initiated) for each of your SAML integrations.

Access keys are not controlled by SAML

This means that if a user has been turned off on the SSO side, their access keys would still be valid. For this reason, administrators should audit users regularly and disable access keys when necessary.

SAML does not provide a deprovisioning mechanism 

This means that if a user is deleted or disabled in the SSO database, it will not be reflected in Sumo Logic. However, these users would no longer be able to login to Sumo Logic via SSO. Administrators can delete these users from the Administration > Users and Roles > Users page in Sumo Logic. When this is done, the user’s content is copied to the administrator who performed the deletion. The exception is access keys, and if SAML lockdown is not enabled, users would still be able to login via native accounts.

Only one certificate for each SAML configuration is currently supported

Only one token-signing ADFS X.509 for each SAML configuration is currently supported. When you need to do a certificate refresh on the ADFS server, you must update the Sumo certificate afterwards.


Before provisioning SAML, make sure you have the following:

  • An installed Identity Provider (IdP) SSO system that supports SAML 2.0. Several SAML IdPs are available. If your organization's IdP supports SAML 2.0 you can configure SAML in Sumo Logic. Examples: Microsoft ADFS, Okta, OneLogin.
  • X.509 certificate. This certificate is used to verify the signature in SAML assertions.
  • Valid email address. An Email Attribute is required in the assertion: either the SAML Subject or another SAML attribute per the SAML configuration. The value of the Email Attribute must be a valid email address. It is used to uniquely identify the user in the organization.

Configure SAML in Sumo

Most of the information required for this procedure can be gathered from your IdP; the other options should be covered by your internal access policy.

  1. Go to Administration > Security > SAML.
  2. Select an existing configuration, or click the plus (+) icon to create a new configuration.
  3. Enter the following information. See Set Up ADFS to Authenticate Sumo Logic Users for specific information about using Microsoft ADFS as a SAML solution to configure Sumo Logic users.
    • Configuration Name: Enter a name to identify the SSO policy (or another name used internally to describe the policy).
    • Debug Mode: Select this option if you'd like to view additional details if an error occurs when a user attempts to authenticate. For more information, see View SAML Debug Information.
    • Issuer: Enter the unique URL assigned to your organization by the SAML IdP. 
      ADFS example:
    • Authn Request URL: Enter the URL that the IdP has assigned for Sumo Logic to submit SAML authentication requests to the IdP.  This field is required if you check the SP Initiated Login Configuration checkbox, described below.

      ADFS example:
    • X.509 Certificate: Copy and paste your organization's X.509 certificate, which is used to verify signatures in SAML assertions. For ADFS, the certificate required is the Token-signing ADFS X.509 certificate.
    • SP Initiated Login Configuration: When you click this option, a Login Path field appears. Enter a unique identifier for your organization. You can specify any alphanumeric string, provided that it is unique to your organization such as "yourcompanyname". The identifier is used to generate a unique URL for user login.

      For example, if you enter "yourcompanyname", the login URL for the HTTP redirect binding becomes:
      And the login URL for the HTTP POST binding becomes:
      where deployment is your specific deployment: us2|eu|au
    • Attribute Mapping: Depending on your IdP, select: 
      • Use SAML subject
      • Use SAML attribute and type the email attribute name in the text box.
    • Roles Attribute: When you click this option, Roles Attribute field appears. Enter the SAML Attribute Name that is sent by the IdP as part of the assertion. For details, see Set Up Optional SAML features.
    • On Demand Provisioning (optional): Select this option and specify the following attributes to have Sumo Logic automatically create accounts when a user first logs on. For more information, see Set Up Optional SAML features.
      • First Name Attribute: You might need to provide the full attribute path, which can vary based on the ADFS version (the actual path can be seen in the SAML assertion). The following are examples.
      • Last Name Attribute: You might need to provide the full attribute path, which can vary based on the ADFS version (the actual path can be seen in the SAML assertion). The following are examples.
    • On Demand Provisioning Roles:  Specify the Sumo RBAC roles you want to assign when user accounts are provisioned. (The roles must already exist.)
    • Logout Page: Select this option and enter a URL if you'd like to point all users to the URL after logging out of Sumo Logic. For more information, see Set Up Optional SAML Features.
  4. Click Add.
  5. To view the details of your configuration, select it the Configuration List. The right side of the page displays the following information. You'll need to provide one of these URLs when you configure settings for your IdP.
    • If your IdP requires HTTP-POST binding, copy the POST URL and paste it into your IdP’s site.
    • If your IdP requires HTTP-REDIRECT binding, copy the Redirect URL and paste it into your IdP’s site.
      Configure SAML details
  6. Click Configure if you need to modify any settings. Click X to close the dialog box. 

Create Multiple SAML Configurations

You can create multiple SAML configurations in Sumo. To create an additional SAML configuration, click the plus (+) icon to create a new configuration. Enter the settings for the new configuration, as described the previous section.


Check SAML Usage

If you intend to require Sumo users to sign-in using SAML, as described in the following section, Require SAML for sign-in, it is a best practice to first check whether some users are still logging in directly, instead of using SAML. You can run the following query to see, for a particular time range, whether users signed in using SAML or with their username and password:

_index=sumologic_audit action=login | count by class, sourceuser 

The query results show, for each user that has accessed Sumo over the time range, the number of times they have logged in using SAML or by entering a Sumo username and password. In the class column:

  •  "SAML" indicates the user signed in using SAML.  
  •  "SESSION" indicates the user authenticated by entering a username and password.  

If the same user accessed Sumo using both methods (SAML and direct logon) during the time range, the query results will include a row for each method, showing how many times each method was used. 


Require SAML for sign-in 

After you create a SAML configuration, you can require users to sign-in using SAML and prevent users from bypassing SAML with a username and password for login.

Select to enforce your login policy.


Sumo automatically adds your account under Allow these users to sign in using passwords in addition to SAML as a whitelisted user as a preventative measure to ensure you’re still able to access Sumo if you run into issues.

Having only one user able to bypass SAML may not be convenient or practical if you have a global company or a large team. You can add additional whitelisted users by clicking the (+) icon by Allow these users to sign in using passwords in addition to SAML:


We do not recommend denying all users password access to Sumo even if you want to enforce log in by SAML. If you attempt to delete your last remaining whitelisted user, you will receive a warning that this is not a recommended practice: