Set Up SAML for Single Sign-On

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.

Configure SP-initiated Login 

This section has instructions for setting up SP-initiated login. In this configuration, when a Sumo user logs in, Sumo redirects the user to your IdP with a SAML AuthnRequest. The request contains the information that your IdP needs to authenticate the user. Your IdP replies to Sumo with a SAML Assertion (SAMLResponse).

In the steps below, you provide the information necessary for Sumo to issue the AuthnRequest to your IdP.

1. Click SP Initiated Login Configuration in the Optional Settings section of the SAML configuration page.  When you click this option, the Login Path and Authn Request URL fields appear. 

2. Login Path. Enter a unique identifier for your org. You can specify any alphanumeric string (with no embedded spaces), provided that it is unique to your org. (You can't configure a Login Path that another Sumo customer has already configured). 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 will be:

   https://service.deployment.sumologic.com/sumo/saml/redirect/yourcompanyname

   And the login URL for the HTTP POST binding will be:

   https://service.deployment.sumologic.com/sumo/saml/post/yourcompanyname

   where deployment is your specific deployment: us2|eu|au

3. 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 checked the SP Initiated Login Configuration checkbox.
   
   ADFS example:
   
   https://adfs.myserver.tld/adfs/ls/

4. Disable Requested Authn Context. If you check this option, Sumo will not include the RequestedAuthnContext element of the SAML AuthnRequests it sends to your Idp. This option is useful if your IdP does not support the RequestedAuthnContext element

5. (Optional) Sign Authn Request. If you select this option, Sumo will send signed Authn requests to your IdP. When you click this option, a Sumo-provided X-509 certificate is displayed. You can configure your IDP with this certificate, to use to verify the signature of the Authn requests sent by Sumo. 

6. If you are done configuring optional SAML features, click Add to save your changes, and proceed to Review SAML configuration. To configure optional SAML features, see the following section. 

Configure on-demand roles provisioning 

If you enable the Roles Attribute option, Sumo Logic assigns roles to a user every time the user logs in. Roles are configured by your IdP and assigned as part of the SAML assertion. For this feature, you must have:

• Configured an group on your IdP for each Sumo role, with the same name as the Sumo role. For example, you should have an “Administrator” group in your  IdP, just as you have an “Administrator” role in Sumo.
• Assigned your Sumo users to the appropriate groups in your IdP, based on the Sumo roles you want to assign to each user.  

1. Click the Roles Attribute checkbox. The Roles Attribute field appears.
2. Roles Attribute. Enter the SAML Attribute Name that is sent by the IdP as part of the assertion. For example, "Sumo_Role".
3. If you are done configuring optional SAML features, click Add to save your changes, and proceed to Review SAML configuration. To configure optional SAML features, see the following section. 

Configure on-demand user account provisioning

If you configure on-demand provisioning, Sumo Logic automatically creates a user account the first time a user logs on to Sumo. To complete this procedure, you need to supply the First Name and Last Name attributes your IdP uses to identify users.

When the account is created, Sumo Logic credentials are emailed to the user. (Users need both Sumo Logic credentials and SAML permissions.)

1. Click the On Demand Provisioning checkbox.
2. 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.
   
   http://schemas.microsoft.com/ws/2008/06/identity/claims/givenname
    
3. 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.
   
   http://schemas.microsoft.com/ws/2008/06/identity/claims/surname
    
4. On Demand Provisioning Roles. Specify the Sumo RBAC roles you want to assign when user accounts are provisioned. (The roles must already exist.)
5. If you are done configuring optional SAML features, click Add to save your changes, and proceed to Review SAML configuration.  

Configure logout page

Configure a logout page if you would like to point Sumo users to a particular URL after logging out of Sumo Logic or after their session has timed out. You could choose your company's intranet, for example, or any other site that you'd prefer users in your organization access.

1. Click the Logout Page checkbox.
2. Enter the URL of the page to which you want to direct users after logging of Sumo.
3. Click Add to save your configuration, and proceed to Review SAML configuration.  

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