• EnglishEspañol日本語한국어Português
  • Log inStart now

Authentication domains: How your users log in and are managed


This doc is for managing users on our newer user model. For managing users on our original user model, see Original users.

To manage their users, New Relic organizations can configure one or more authentication domains, which control how users are added to a New Relic account, how they're authenticated, and more.

Authentication domains explained

An authentication domain is a grouping of New Relic users governed by the same user management settings, like how they're provisioned (added and updated) and how they're authenticated (logged in).

When you create a New Relic organization, the default authentication settings are:

  • Source of users: your users are added to New Relic using only our user management tools (not third party tools)
  • Authentication: users log in using their email and password

Those default settings would be under one authentication domain. If you added another authentication domain, you might set it up like this:

  • Source of users: Users are added and managed from a third-party identity provider via SCIM provisioning
  • Authentication: users are logged in using SAML single sign-on (SSO) from an identity provider

When you add users to New Relic, they're always added to a specific authentication domain. Typically organizations have either one or two authentication domains: one with the manual methods and one for the methods associated with an identity provider. Learn more in this short video (4:26 minutes):


Authentication domains are for managing users on our newer user model. If your users are on our original user model, see Original accounts.

Requirements to manage authentication domains:

  • Your organization must be either Pro or Enterprise edition to have editable authentication domains.
  • To view or edit authentication domains, a user must:
  • SCIM provisioning, also known as automated user management, requires Pro or Enterprise edition. Learn more about requirements.
  • SAML SSO requires a paid edition. Our SAML SSO support includes:
    • Active Directory Federation Services (ADFS)
    • Auth0
    • Azure AD (Microsoft Azure Active Directory)
    • Google
    • Okta
    • OneLogin
    • Ping Identity
    • Salesforce
    • Generic support for SSO systems that use SAML 2.0

Create and configure an authentication domain

If you meet the requirements, you can add and manage authentication domains.

To view and configure authentication domains: from the user menu, go to Administration > Authentication domains.

If you have existing domains, they'll be on the left. Note that most organizations will have, at most, two or three domains: one with the manual, default settings and one or two for the identity provider-associated settings.

To create a new domain from the authentication domain UI page, click Create authentication domain. For more about the configuration options, keep reading.

Switch to different domains

If you have user records in more than one authentication domain, you can switch between domains.

Source of users: how your users are added and managed


For an introduction to our SAML SSO and SCIM offerings, please read Get started with SSO and SCIM.

From the authentication domain UI, you can set one of two options for the source of your users:

  • Manual (default): This means that your users are added manually to New Relic from the User management UI.
  • SCIM: Our automated user management feature allows you to use SCIM provisioning to import and manage users from your identity provider.

Notes on these settings:

  • You can't toggle Source of users. This means if you want to change this for an authentication domain that's already been set up, you'll need to create a new one.
  • When you first enable SCIM, the bearer token is generated and only shown once. If you need to view a bearer token later, the only way to do this is to generate a new one, which will invalidate the old one and any integrations using the old token.

For how to set up SCIM, see Automated user management.

Method of managing user type

In the Authentication Domain UI, if you've selected SCIM for your method of provisioning users, you have two options for how your users' user type is managed:

  • Manage user type in New Relic: This is the default option. It allows you to manage your users' user type from New Relic.
  • Manage user type with SCIM: Enabling this means that you can no longer manage user type from New Relic. You'd only be able to change and manage it from your identity provider.

More on these two options:

Note that if you're on our original user model, upgrades work differently.

Authentication: how your users log in

The authentication method is the way in which New Relic users log in to New Relic. All users in an authentication domain have a single authentication method. There are two authentication options:

  • Username/password (default): Your users log in via email and password.
  • SAML SSO: Your users log in via SAML single sign-on (SSO) using your identity provider. To learn how to set that up, keep reading.

Set up SAML SSO authentication

Before enabling SAML SSO using the instructions below, here are some things to understand and consider:

  1. If you're setting up SCIM provisioning:

    • If you use Azure, Okta, or OneLogin, follow these procedures first: Azure | OneLogin | Okta.
    • If you use a different identity provider, follow the SAML procedures below and use our SCIM API to enable SCIM.
  2. If you only want to enable SAML SSO and not SCIM, and if you use Azure, Okta, or OneLogin, follow these instructions for configuring the relevant app:

    • If you're implementing SAML using a different identity provider not mentioned above, you'll need to attempt to integrate using the SAML instructions below. Note that your identity provider must use the SAML 2.0 protocol, and must require signed SAML assertions.
  3. Next, you'll go to our authentication domain UI. From the user menu, click Administration, and then click Authentication domains. If you don't already have one, create a new domain to be used for your SAML-authenticating users.

  4. Under Authentication, click Configure. Under Method of authenticating users, select SAML SSO.

  5. If you're using the Okta, OneLogin, or Azure AD app, you can skip this step. Under Provided by New Relic, we have some New Relic-specific information. You'll need to place these in the relevant fields in your identity provider service. If you're not sure where they go, consult your identity provider docs.

  6. Under Provided by you, input the Source of SAML metadata. This URL is supplied by your identity provider and may be called something else. It should conform to SAML V2.0 metadata standards. If your identity provider doesn't support dynamic configuration, you can do this by using Upload a certificate. This should be a PEM encoded x509 certificate.

  7. Under Provided by you, set the SSO target URL supplied by your identity provider. You can find this by going to the Source of SAML metadata and finding the POST binding URL. It looks like: https://newrelic.oktapreview.com/app/newreliclr/1234567890abcdefghij/sso/saml.

  8. If your identity provider has a redirect URL for logout, enter it in the Logout redirect URL; otherwise, leave it blank.

  9. If you're using an identity provider app, you'll need to input the authentication domain ID in the app. That ID is found at the top of New Relic's authentication domain UI page.

  10. Optional: In New Relic's authentication domain UI, you can adjust other settings, like browser session length and user upgrade method. You can adjust these settings at any time.

  11. If you're enabling SAML only, you'll need to create groups. (If you enabled SCIM, you've already completed this step.) Groups are what give your users access to New Relic accounts. Without being assigned to groups, your users are provisioned in New Relic but have no access to accounts or roles. To learn how to do this:

  1. Okta only: Return to Okta's New Relic app and, from the Add New Relic by organization page, uncheck the two Application visibility "Do not display..." checkboxes and click on Done.

To verify it's been set up correctly, see if your users can log in to New Relic via your identity provider and ensure they have access to their accounts.

Other user-related settings

To manage session-related settings, and whether users can self-upgrade or not:

  1. From the User management UI, select an authentication domain from the switcher.
  2. Click the gear icon .
  3. Edit the settings, which are described in more detail below.

Session-related settings

Session-related settings include:

User upgrade settings

Settings related to how users upgrade to higher user type include:

  • Automatic approval: This allows users to be able to immediately upgrade to a higher user type on their own, without approval. This allows these users to be able to more quickly respond to issues.
  • Require review: With this option, admins (users with the Authentication domain administration setting) receive an email when a user requests an upgrade, and can approve or deny those requests in the User management UI.
    • A user is limited to 6 upgrade requests over a 24-hour sliding window. For example, if you make your 6 upgrade requests between 8am to 10am, then you're required to wait until 8am the next day before making another upgrade request.
Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.