Pour gérer leurs utilisateurs, les organisations New Relic peuvent configurer un ou plusieurs domaines d'authentification, qui contrôlent la manière dont les utilisateurs sont ajoutés à un compte New Relic , comment ils sont authentifiés, etc.
Domaine d'authentification expliqué
Un authentication domain est un regroupement d'utilisateurs New Relic régi par les mêmes paramètres de gestion des utilisateurs, comme la façon dont ils sont provisionnés (ajoutés et mis à jour) et la façon dont ils sont authentifiés (connectés).
Lorsque vous créez une organisation New Relic, les paramètres d'authentification par défaut sont :
- Méthode de provisionnement des utilisateurs : Manuel
- Les utilisateurs sont ajoutés via notre interface utilisateur de gestion des utilisateurs ou notre API Nerdgraph
- Méthode de gestion du type d'utilisateur : gérer avec New Relic
- Le type d'utilisateur des utilisateurs est géré par vous via notre Interface utilisateur de gestion des utilisateurs ou notre API Nerdgraph
- Méthode d'authentification des utilisateurs : Nom d'utilisateur / mot de passe
- Les utilisateurs se connectent directement à New Relic en utilisant une adresse e-mail et un mot de passe
Ces paramètres par défaut seraient sous un seul domaine d'authentification. Si vous avez ajouté un domaine d'authentification supplémentaire, vous pouvez le configurer comme ceci :
- Méthode de provisionnement des utilisateurs : SCIM
- Les utilisateurs sont ajoutés et gérés via l'approvisionnement SCIM à partir d'un fournisseur d'identité tiers tel que Okta, OneLogin, Azure/Entra ou via notre API SCIM
- Méthode d'authentification des utilisateurs : SAML SSO
- Les utilisateurs se connectent à l'aide de l'authentification unique (SSO) SAML à partir d'un fournisseur d'identité tel que Okta, OneLogin, Azure/Entra
Lorsque vous ajoutez des utilisateurs à New Relic, ils sont toujours ajoutés à un domaine d'authentification spécifique. Généralement, les organisations ont un ou deux domaines d'authentification : un avec les méthodes manuelles et un pour les méthodes associées à un fournisseur d'identité.
Exigences
Pour gérer le domaine d’authentification :
Votre organisation doit être en édition Pro ou Enterprise pour avoir un domaine d'authentification modifiable.
Pour visualiser ou modifier le domaine d'authentification, un utilisateur doit :
- Avoir un type d'utilisateur d'utilisateur principal ou d'utilisateur de plateforme complète.
- Soyez dans un groupe avec le paramètre d'administrationAuthentication domain .
Le provisionnement SCIM, également connu sous le nom de gestion automatisée des utilisateurs, nécessite Pro ou l'édition Enterprise. En savoir plus sur les exigences.
SAML SSO nécessite une édition payante. Notre support SAML SSO comprend :
Active Directory Federation Services (ADFS)
Auth0
Azure AD (Microsoft Azure Active Directory)
Google
Okta
OneLogin
Ping Identity
Salesforce
Prise en charge générique pour les systèmes SSO utilisant SAML 2.0
Créer et configurer un domaine d'authentification
Si vous remplissez les conditions, vous pouvez ajouter et gérer un domaine d'authentification.
Pour visualiser et configurer le domaine d'authentification : depuis le menu utilisateur, allez à Administration > Authentication domains.
Si vous avez un domaine existant, ils seront dans le tableau. Notez que la plupart des organisations auront, au maximum, deux ou trois domaines : un avec les paramètres manuels par défaut et un ou deux pour les paramètres associés au fournisseur d'identité.
Pour créer un nouveau domaine à partir de la page UI du domaine d’authentification, cliquez sur Create authentication domain. Pour gérer ou supprimer un domaine d’authentification, sélectionnez l’élément de menu pour chaque domaine d’authentification.
Passer à un autre domaine
Si vous avez des enregistrements d'utilisateur dans plusieurs domaines d'authentification, vous pouvez basculer entre les domaines.
Méthode de provisionnement des utilisateurs : comment vos utilisateurs sont ajoutés et gérés
Conseil
- Pour une introduction à nos offres SAML SSO et SCIM, consultez Premiers pas avec SSO et SCIM.
- Nous vous recommandons d'envisager d'implémenter la capture de domaines qui vous permet d'ajouter automatiquement des utilisateurs à votre organisation en fonction de leur domaine de messagerie. Cela empêche l'utilisateur de s'inscrire accidentellement sur New Relic et de créer une organisation New Relic inutile et indésirable. Cette fonctionnalité est disponible pour les comptes Pro et Entreprise.
À partir de l'interface utilisateur du domaine d'authentification, vous pouvez définir l'une des deux options pour la « Méthode de provisionnement des utilisateurs » :
- SCIM: Notre fonctionnalité de gestion automatisée des utilisateurs vous permet d'utiliser l'approvisionnement SCIM à partir d'un fournisseur d'identité tiers.
- Manual: Cela signifie que vos utilisateurs sont ajoutés manuellement à New Relic via l'Interface utilisateur de gestion des utilisateurs ou notre API Nerdgraph
Remarques sur ces paramètres :
- Vous ne pouvez pas basculer Method of provisioning users. Cela signifie que si vous souhaitez modifier cela pour un domaine d'authentification déjà configuré, vous devrez créer un nouveau domaine d'authentification.
- Lorsque vous activez SCIM pour la première fois, le jeton porteur est généré et n'est affiché qu'une seule fois. Si vous devez afficher un jeton porteur ultérieurement, la seule façon de le faire est d'en générer un nouveau, ce qui invalidera l'ancien et toutes les intégrations utilisant l'ancien jeton ne pourront plus s'approvisionner avec succès
Pour savoir comment configurer SCIM, voir Gestion automatisée des utilisateurs.
Méthode de gestion du type d'utilisateur
Dans le Authentication Domain UI, si vous avez sélectionné SCIM comme méthode d'approvisionnement des utilisateurs, vous avez deux options pour la gestion du type d'utilisateur :
- Manage user type in New Relic:Il s'agit de l'option par défaut. Il vous permet de gérer le type d'utilisateur de votre utilisateur depuis New Relic.
- Manage user type with SCIM: L'activation de cette option signifie que vous ne pouvez plus gérer le type d'utilisateur depuis New Relic. Vous ne pourrez le modifier et le gérer qu'à partir de votre fournisseur d'identité.
En savoir plus sur ces deux options :
Authentification : comment votre utilisateur se connecte
La méthode d'authentification est la manière dont l'utilisateur New Relic se connecte à New Relic. Tous les utilisateurs d'un domaine d'authentification ont une seule méthode d'authentification. Il existe deux options d'authentification :
- Nom d'utilisateur/mot de passe (par défaut) : Votre utilisateur se connecte via email et mot de passe.
- SAML SSO: Votre utilisateur se connecte via SAML single sign-on (SSO) en utilisant votre fournisseur d'identité. Pour savoir comment configurer cela, continuez à lire.
Configurer l'authentification SSO SAML
Avant d'activer SAML SSO à l'aide des instructions ci-dessous, voici quelques éléments à comprendre et à prendre en compte :
- Pensez à lire une introduction à New Relic SSO et SCIM.
- Pensez à revoir les exigences SSO SAML.
- Pensez à regarder une vidéo expliquant comment configurer SAML SSO.
- Notez que votre utilisateur compatible SSOne recevra pas de notification de vérification par e-mail de New Relic car les informations de connexion et de mot de passe sont gérées par votre fournisseur d'identité.
- Consultez la documentation de votre fournisseur d'identité, car elle peut contenir des instructions spécifiques à New Relic.
Si vous configurez le provisionnement SCIM :
Si only souhaitez activer SAML SSO et non SCIM, et si vous utilisez Azure, Okta ou OneLogin, suivez ces instructions pour configurer l'application concernée :
- Si vous implémentez SAML à l’aide d’un autre fournisseur d’identité non mentionné ci-dessus, vous devrez tenter de l’intégrer à l’aide des instructions SAML ci-dessous. Notez que votre fournisseur d’identité doit utiliser le protocole SAML 2.0 et doit exiger des assertions SAML signées.
Ensuite, vous accéderez à notre UI de domaine d’authentification. Dans le menu utilisateur, cliquez sur Administration, puis sur Authentication domains. Si vous n'en avez pas déjà un, créez un nouveau domaine à utiliser pour votre utilisateur d'authentification SAML.
Sous Authentication, cliquez sur Configure. Sous Method of authenticating users, sélectionnez SAML SSO.
Si vous utilisez l’application Okta, OneLogin ou Azure AD, vous pouvez ignorer cette étape. Sous Provided by New Relic, nous avons quelques informations spécifiques à New Relic. Vous devrez les placer dans les champs appropriés de votre service de fournisseur d'identité. Si vous n'êtes pas sûr de leur destination, consultez la documentation de votre fournisseur d'identité.
Sous Provided by you, saisissez le Source of SAML metadata. Cette URL est fournie par votre fournisseur d’identité et peut être appelée autrement. Il doit être conforme aux normes de métadonnées SAML V2.0. Si votre fournisseur d'identité doesn't prend en charge la configuration dynamique, vous pouvez le faire en utilisant Upload a certificate. Il doit s'agir d'un certificat x509 codé PEM.
Sous Provided by you, définissez le SSO target URL fourni par votre fournisseur d’identité. Vous pouvez le trouver en allant dans Source of SAML metadata et en trouvant l'URL de liaison POST. Cela ressemble à :
https://newrelic.oktapreview.com/app/newreliclr/1234567890abcdefghij/sso/saml.Si votre fournisseur d'identité dispose d'une URL de redirection pour la déconnexion, saisissez-la dans le champ Logout redirect URL; sinon, laissez-la vide.
Si vous utilisez une application de fournisseur d’identité, vous devrez saisir l’ID de domaine d’authentification dans l’application. Cet identifiant se trouve en haut de la page UI du domaine d'authentification de New Relic.
Facultatif : dans l'UI du domaine d'authentification de New Relic, vous pouvez ajuster d'autres paramètres, comme la durée de la session du navigateur et la méthode de mise à niveau de l'utilisateur. Vous pouvez ajuster ces paramètres à tout moment.
Si vous activez uniquement SAML, vous devrez créer des groupes. (Si vous avez activé SCIM, vous avez déjà terminé cette étape.) Les groupes sont ce qui donne à votre utilisateur l'accès aux comptes New Relic. Sans être affectés à des groupes, vos utilisateurs sont provisionnés dans New Relic mais n'ont pas accès aux comptes ou aux rôles. Pour apprendre à faire cela :
- Découvrez comment fonctionne l'accès au groupe d'utilisateurs
- Lire le tutoriel de gestion utilisateur.
- Okta uniquement : revenez à l'application New Relic d'Okta et, à partir de la page Add New Relic by organization , décochez les deux cases Application visibility "Do not display..." et cliquez sur Done.
Pour vérifier que la configuration a été correctement effectuée, vérifiez si votre utilisateur peut se connecter à New Relic via votre fournisseur d'identité et assurez-vous qu'il a accès à ses comptes.
Autres paramètres liés à l'utilisateur
Pour gérer les paramètres liés à la session et savoir si l’utilisateur peut effectuer lui-même la mise à niveau ou non :
- Depuis l’ UIUser management , sélectionnez un domaine d’authentification à partir du commutateur.
- Cliquez sur l'icône d'engrenage .
- Modifiez les paramètres, qui sont décrits plus en détail ci-dessous.
Paramètres liés à la session
Les paramètres liés à la session incluent :
- Durée pendant laquelle l'utilisateur peut rester connecté
- Durée d'inactivité avant l'expiration de la session d'un utilisateur (en savoir plus sur les limites de session)
Paramètres de mise à niveau de l'utilisateur
Les paramètres liés à la manière dont l'utilisateur est mis à niveau vers un type d'utilisateur supérieur incluent :
- Automatic approval:Cela permet à l'utilisateur de pouvoir immédiatement passer à un type d'utilisateur supérieur par lui-même, sans approbation. Cela permet à ces utilisateurs de pouvoir répondre plus rapidement aux problèmes.
- Require review:Avec cette option, l'administrateur de l'utilisateur avec le paramètre d'administrationAuthentication domain reçoit un e-mail lorsqu'un utilisateur requests une mise à niveau et peut approuver ou refuser ces requests dans l'UIUser management .
- Un utilisateur est limité à 6 requests de mise à niveau sur une fenêtre glissante de 24 heures. Par exemple, si vous effectuez vos 6 requests de mise à niveau entre 8h et 10h, vous devrez attendre jusqu'à 8h le lendemain avant d'effectuer une autre demande de mise à niveau.