Principes de base de l'authentification et de l'autorisation

L'authentification et l'autorisation jouent un rôle important dans la plupart des suites d'applications. Cette page fournit un aperçu général des concepts et de la terminologie. Il sera utile si vous êtes nouveau sur le sujet ou si vous souhaitez un rappel. Si vous êtes sûr de bien comprendre les notions générales, vous pouvez passer à l'apprentissage du fonctionnement de l'authentification et de l'autorisation dans NiCE CXone.

Lorsque les utilisateurs se connectent à n'importe quelle suite d'applications, y compris NiCE CXone, ces deux étapes se produisent généralement dans l'ordre indiqué :

  • Authentification—L'utilisateur est-il celui qu'il prétend être ?
  • Autorisation—L'utilisateur authentifié doit-il avoir l'accès qu'il a demandé ?

Tous les utilisateurs doivent être authentifiés et autorisés avant de pouvoir accéder à NiCE CXone.

Les utilisateurs peuvent être des gens ou des applications. Par exemple, les chatbots et les assistants virtuels s'exécutent souvent au moyen d'un compte utilisateur. La plupart des suites d'applications utilisent les mêmes processus pour les utilisateurs humains et virtuels. Dans ces pages d'aide en ligne sur l'authentification et l'autorisation, nous avons utilisé le terme utilisateur pour désigner à la fois les gens et les applications. S'il y a des différences, elles sont clairement expliquées.

Du point de vue de l'utilisateur, il s'agit simplement d'une connexion. L'authentification et l'autorisation se déroulent en arrière-plan pour que leur connexion soit un succès. Au début d'une connexion, les utilisateurs ne sont pas authentifiés. Cela signifie que le système ne connaît pas leur identité. À la fin de la connexion, ils sont tous les deux authentifiés et autorisés. Cela signifie que le système sait qui ils sont et quel accès ils devraient avoir.

Un système effectue les opérations suivantes pour authentifier et autoriser les utilisateurs :

  1. Détermine quel processus d'authentification utiliser si plus qu'un est pris en charge. De nombreux systèmes prennent en charge plusieurs méthodes. Par exemple, les systèmes peuvent identifier les utilisateurs à l'aide d'un nom d'utilisateur et d'un mot DE passe, via l'authentification unique, ou via l'authentification multifactorielle (Amf). En général, les utilisateurs choisissent parmi une liste d'options d'authentification sur la page de connexion, mais les systèmes peuvent exiger un processus spécifique lorsque cela est nécessaire.

  2. Rassemble les identifiants d'authentification (par exemple, en demandant aux utilisateurs leur nom d'utilisateur et leur mot DE passe).

  3. Vérifie les informations d'identification à l'aide d'un fournisseur d'identité. Un fournisseur d'identité est un système distinct qui conserve des informations sur les utilisateurs et leur identité, y compris leurs informations d'identification.

  4. Autorise la personne ou le programme authentifié. une fois les utilisateurs authentifiés, le système utilise un serveur d'autorisation pour accorder l'accès à l'utilisateur. Le système accorde l'accès à l'utilisateur en fonction de son rôle et de ses autorisations. Le système accorde à l'utilisateur l'accès uniquement aux fonctionnalités pour lesquelles il dispose de l'autorisation de les afficher ou de les utiliser.

Terminologie liée à l'authentification

Fournisseur d’identité

Les fournisseurs d'identité (IdP) sont des systèmes qui établissent l'identité d'un utilisateur. Ils peuvent être:

  • Interne—Partie du système à laquelle l'utilisateur se connecte. Par exemple, un utilisateur se connectant à Facebook utilise l'IdP Facebook pour s'authentifier auprès de l'application Facebook.
  • Externe—Séparé du système auquel l'utilisateur se connecte. Par exemple, un utilisateur se connecte à une application pour smartphone à l'aide de l'authentification IdP Facebook.

Les IdP peuvent être hébergés ou basés sur le cloud. Microsoft ADFS et Shibboleth sont des IdP hébergés courants. Microsoft Azure AD, Okta et Ping font partie des nombreux IdP cloud.

Protocoles d'authentification

Les protocoles d'authentification établissent la communication entre les applications et les IdP, ou entre différents IdP. OpenID Connect et SAML 2.0 sont des exemples de protocoles d'authentification. Certaines protocoles d'authentification offrent des fonctionnalités supplémentaires, telles que le chiffrement, mais les applications peuvent utiliser ou non ces fonctionnalités. Lorsqu'un système utilise un fournisseur d'identité intégré, les protocoles d'authentification ne sont pas pris en compte.

Flux d'authentification

La plupart des fournisseurs d'identité externes prennent en charge l'un des flux suivants ou les deux pour le processus d'authentification :

  • **SP-initiated** : L'authentification est initiée par le fournisseur de services, ou l'application. L'utilisateur saisit ses informations d'identification et l'application contacte un fournisseur d'identité externe pour vérification d'identité. C'est le flux le plus courant.
  • Initié par IdP : les utilisateurs se connectent (connexion) d'abord à l'IdP, puis l'IdP lance les applications après avoir vérifié l'utilisateur.

Gestion des identités fédérées

La Gestion des identités fédérées est parfois appelée FIM ou fédération. Il s'agit d'un terme générique désignant le processus consistant à utiliser un seul IdP externe pour fournir l'authentification pour une ou plusieurs applications. La fédération est généralement limitée dans le temps d'une manière ou d'une autre. Par exemple, un utilisateur peut se connecter une fois lorsqu'il commence à travailler. Cela leur permet de s'authentifier auprès de toutes les applications qu'ils utilisent chaque jour. Cependant, ils devront se reconnecter le lendemain pour se réauthentifier, même s'ils ne se sont pas déconnectés la veille.

Authentification unique

L'authentification unique (SSO) est utilisée pour fournir l'accès à plusieurs applications ou systèmes à partir d'une seule connexion. Par exemple, un utilisateur se connecte à Microsoft 365 et obtient l'accès à toutes les applications Microsoft que son entreprise a autorisées pour lui. Parfois, le terme SSO est utilisé pour la fédération, bien que les deux concepts ne soient pas exactement les mêmes.

Authentification multifacteur

L'authentification multifacteur (Amf) ajoute un niveau de sécurité supplémentaire à l'authentification de base par nom d'utilisateur/mot DE passe. L'Amf demande à l'utilisateur de saisir un code, de répondre à une question ou d'utiliser un jeton avant que l'IdP ne considère son identité vérifiée.

Confiance

Dans l'authentification, la confiance fait référence aux informations ou aux connaissances partagées par une application ou un système et un fournisseur d'identité externe. Cette connaissance établit une relation entre les deux parties, de sorte que chacune sait qu'elle peut se fier à une communication exacte et sincère de la part de l'autre. La façon dont la confiance est établie diffère selon le protocole d'authentification. The following examples are based on OpenID Connect and SAML 2.0.

OpenID Connect

La confiance dans OpenID Connect est basée sur l'émetteur. Un émetteur est une valeur qui ressemble à une URL. Il établit votre fournisseur d’identité. Par exemple, Google prend en charge OpenID Connect et l'émetteur est https://accounts.google.com.

En fonction de l'émetteur, il existe plusieurs éléments de configuration supplémentaires. Par exemple, dans OpenID Connect, la confiance est établie par le biais de la signature de certificats public/privé. Il utilise une norme industrielle appelée JWKS. Par conséquent, une partie de la configuration détermine comment ces certificats publics sont obtenus.

La plupart des fournisseurs d'identité prennent en charge la découverte de ces informations en ajoutant /.well-known/openid-configuration à l'émetteur. Le document de découverte de Google se trouve sur https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

Dans SAML 2.0, la confiance est basée sur un identifiant d'entité. Contrairement à OpenID Connect, il n'existe pas de relation forte entre l'identifiant d'entité et les autres valeurs de configuration. Plusieurs paramètres de configuration sont utilisés pour établir la confiance avec SAML 2.0:

  • Identifiant de l'entité—Valeur établie par l'application ou le système pour vérifier son identité

  • URL du point de terminaison—Valeur déterminée par l'IdP externe auquel il reçoit les demandes d'authentification

  • URL d'assertion—Valeur déterminée par l'application ou le système auquel l'IdP externe envoie des réponses d'authentification

  • Certificat—Utilisé par l'IdP externe pour signer la réponse