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 avez confiance en votre compréhension générale, vous pouvez passer à l'apprentissage comment l'authentification et l'autorisation fonctionnent dansCXone.

Lorsque les utilisateurs se connectent à n'importe quelle suite d'applications, y compris 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 à CXone.

Du point de vue de l'utilisateur, il se connecte simplement. L'authentification et l'autorisation se produisent dans les coulisses pour réussir sa connexion. 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 à la fois 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 le processus d'authentification à utiliser si plusieurs sont pris en charge. De nombreux systèmes prennent en charge plusieurs méthodes. Par exemple, les systèmes peuvent identifier les utilisateurs avec un nom d'utilisateur et un mot de passe, authentification unique ou par authentification multifacteur (MFA). Généralement, les utilisateurs choisissent parmi une liste d'options d'authentification sur la page de connexion, mais les systèmes peuvent nécessiter un processus spécifique si 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 n'accorde à l'utilisateur l'accès qu'aux fonctionnalités qu'il est autorisé à voir ou à utiliser.

Terminologie relative à l'authentification

Fournisseur d'identité

Les fournisseurs d'identité (IdP) sont des systèmes qui établissent l'identité d'un utilisateur. Elles 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 fournisseurs d’identité 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. Certains protocoles d'authentification offrent des fonctionnalités supplémentaires, telles que le cryptage, mais les applications peuvent ou non utiliser 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 :

• Initié par SP : 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 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 fédérée des identités est parfois appelée FIM ou fédération. Il s'agit d'un terme générique désignant le processus d'utilisation d'un fournisseur d'identité externe unique pour fournir une 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 les authentifie 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 un accès à plusieurs applications ou systèmes basés sur une seule connexion. Par exemple, un utilisateur se connecte à Microsoft 365 et accède à 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 (MFA) ajoute un autre niveau de sécurité à 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 afin que chacun sache qu'il peut compter sur une communication précise et véridique de l'autre. La façon dont la confiance est établie diffère selon le protocole d'authentification. Les exemples suivants sont basés sur OpenID Connect et SAML 2.0.

OpenID Connect

Croire en OpenID Connect est basé 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 la signature de certificat 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 étroite 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