Set up SSO Integration on RedLock

To secure administrator access to the RedLock console, go to your identity provider's site to configure single sign-on and then configure the RedLock service for SSO.
On the RedLock admin console, you can enable single sign-on (SSO) using an Identity Provider who supports Security Assertion Markup Language (SAML), such as Okta or PingID. To enable SSO, you must first complete the set up on the Identity Service Provider (IdP). Then, log in with System Admin privilege on the RedLock admin console to configure SSO and redirect login requests to the IdP’s login page, so that your RedLock administrative users can log in using SSO.
After you enable SSO, you must access the RedLock admin console from the IdP’s portal. RedLock supports IdP initiated SSO, and it’s SAML endpoint supports the POST method only.
As a best practice, enable a couple administrative users with both local authentication credentials on the RedLock service and SSO access so that they can log in to the admin console and modify the SSO configuration when needed, without risk of account lockout. Also, any administrator who needs to access the RedLock API cannot use SSO and must authenticate directly to the RedLock service using the email address and password registered with RedLock.
  1. Set up the Identity Provider for SSO.
    1. This workflow uses Okta as the IdP. Before you begin to set up Okta configuration, login to your RedLock Service instance and copy the Audience URI (SP Entity ID) from the RedLock admin console. For example:
    2. Login to Okta as an Administrator and click Admin.
    3. Click Add Applications.
    4. Search for RedLock and Add.
    5. On Create a New Application Integration, select Web for Platform and SAML 2.0 for Sign on method.
    6. Click Create.
    7. On General Settings, use these values and click Next.
      App Name - RedLock SSO app
      App Logo - Use the RedLock logo
      App Visibility - Do not check these options
    8. To Configure SAML, specify the Sign On URL.
      The format for Sign On URL uses the URL for the RedLock admin console, but you must replace app with api and add saml at the end. For example, if you access the RedLock admin console at, your Sign On URL should be and if it is, it should be
    9. For Audience URI - Use the value displayed on RedLock SettingsSSO that you copied in the first step.
    10. Select Name ID format as EmailAddress and Application username as Email.
    11. Click Save.
    12. Assign users who can use the RedLock SSO app to log in to the RedLock service.
      You have now successfully created an application for the SAML integration. This application will have the details of the IdP URL and Certificate which you’ll need to add on the RedLock admin console to complete the SSO integration.
  2. Add the users to RedLock console.
  3. Configure SSO on RedLock.
    1. Log in to Redlock admin console and select SettingsSSO.
    2. Enable SSO.
    3. Audience URI (SP Entity ID) is a read-only field in the format:<string> to uniquely identify your tenant. Use this value in Configure SAML section in your IdP settings.
    4. In Identity Provider Issuer, enter the URL of a trusted provider like Google, Salesforce, Okta, or Ping that act as IDP in the authentication flow.
      On Okta, for example, you can find the Identity Provider issuer URL at ApplicationsSign OnView Setup Instructions.
      In the setup instructions, you have Identity Provider Issuer and RedLock Access SAML URL.
    5. Identity Provider Logout URL You will be re directed to this URL when RedLock Service times out .
    6. Enter your IdP Certificate in the standard X.509 format.
    7. RedLock Access SAML URL is URL specific to the RedLock application which is configured in your IdP settings. For example, on Okta this is the Identity Provider Single Sign-On URL in the screenshot above.
      When you click this URL, after authentication with your IdP, you are redirected to the RedLock service. This link along with the Relay State Parameter is used for all the redirection links embedded in notifications like email, slack, SQS, and compliance reports.
    8. Relay State Param name is SAML specific Relay State parameter name. If you provide this parameter along with RedLock Access SAML URL, all notification links in Splunk, Slack, SQS, email, and reports will have seamless access to the RedLock application. The relay state parameter or value is specific to your Identity Provider. For example, this value is RelayState for Okta.
      When using RelayState functionality, make sure your RedLock Access SAML URL corresponds to Identity Provider Single Sign-On URL ending in ‘/sso/saml’.
    9. Select Allow select users to authenticate directly with RedLock to configure some users to access RedLock console directly using their email address and password registered with RedLock, in addition to logging in via the SSO provider.
      When you enable SSO, make sure to select a few users who can also access the RedLock console directly using the email and password that is registered locally on the RedLock service to ensure that you are not locked out of the console in the event you have misconfigured SSO and need to modify the IdP settings. For accessing data through APIs, you need to authenticate directly to the RedLock service.
    10. Select the Users who can access the RedLock console either using local authentication credentials on the RedLock service or using SSO.
    11. Verify access using SSO.
      Administrative users for whom you have enabled SSO, must access the RedLock admin console from the Identity Provider’s portal. For example, if you have integrated RedLock with Okta, administrative users must login to Okta and then click on the RedLock app icon to be logged in to the RedLock admin console.
    12. Using View last SSO login failures, you can see details of last five login issues or errors for SSO authentication for any users.
    • You can have only one SAML setting for all your cloud accounts.
    • The selection of whitelisted users (the users who can log in using SSO and also through username and password) is independent of the edits to the SSO configuration or enable/disable of SSO.
    • If the user is logged in already via username/password flow, and the user tries to log in via SAML flow, the token will get updated with the latest one in browser's local storage replacing the existing auth-token.

Related Documentation