Connexion unique

La connexion unique est un processus d'authentification avec lequel un utilisateur peut accéder à plusieurs applications en entrant un seul ID utilisateur et un seul mot de passe. Vous pouvez configurer plusieurs applications pour qu'elles utilisent Verify ce système d'authentification et d'autorisation des utilisateurs. Les utilisateurs se connectent aux applications cibles à l'aide de leurs Verify identifiants de compte. Une fois authentifiés via Verify, les utilisateurs peuvent accéder à toutes les applications auxquelles ils ont droit, dans le cadre de la session d'authentification. À l'expiration de la session, les utilisateurs doivent se reconnecter via Verify.

Pour mettre en place l'authentification unique entre Verify et n'importe quelle application cible, celles-ci doivent échanger leurs paramètres de configuration. Vous devez configurer l'application dans Verify et configurer Verify dans l'application cible.

Authentification et autorisation

L'authentification consiste à vérifier l'identité d'un utilisateur, pour confirmer que l'utilisateur est bien la personne qu'il prétend être. L'autorisation consiste à accorder un accès utilisateur à une ressource et à définir les tâches que l'utilisateur peut effectuer avec la ressource. Verify prend en charge l'authentification et l'autorisation via SAML et OpenID Connect.
Tableau 1. Tableau comparatif
SAML 2.0 OpenID Connect
Descriptif

Le Security Assertion Markup Language ( SAML ) est une norme ouverte qui permet l'authentification et l'autorisation.

La norme fournit une infrastructure pour la communication sécurisée d'identités d'utilisateur entre un fournisseur de services et un fournisseur d'identité.

OpenID Connect est un protocole standard ouvert qui combine des fonctionnalités d'authentification ( OpenID ) et d'autorisation ( OAuth2.0 ).

La norme fournit une infrastructure pour la communication sécurisée d'identités d'utilisateur entre une partie utilisatrice et un fournisseur OpenID Connect.

Cas d'utilisation

Connexion unique pour les applications d'entreprise

Connexion unique pour les applications d'entreprise et client

Types de client pris en charge
  • Web
  • Web
  • Mobile ou native
  • JavaScript
Format des données XML JSON
L'authentification ou les informations utilisateur sont envoyées via

Une assertion de type « SAML ».

L'assertion contient les informations suivantes :
  • Le sujet (qui s'est authentifié)
  • Des attributs (informations sur la personne)
  • L'émetteur (qui a émis l'assertion)
  • D'autres informations sur l'événement d'authentification

Un jeton Web JSON (JWT), appelé jeton d'identification.

Le jeton contient les informations suivantes :
  • Le sujet (qui s'est authentifié)
  • L'émetteur (qui a émis les réclamations utilisateur)
  • La date d'expiration de l'authentification
  • Attributs ou informations sur l'utilisateur (informations concernant la personne) 1
  • D'autres informations sur l'événement d'authentification
Jetons Jeton d'accès
  • Jeton d'ID
  • Jeton d'accès. Il peut s'agir d'une chaîne opaque ou d'un jeton au format JWT (jeton Web JSON).
  • Actualiser le jeton
Remarque : les longueurs des jetons OIDC ( OAuth ) ne sont pas fixes. Lors du stockage des jetons d'accès et de rafraîchissement, prévoyez des longueurs variables. Si vous devez définir une longueur maximale pour le stockage et que vous ne prévoyez pas d'utiliser des jetons d'accès au format JWT à l'avenir, prévoyez une longueur de jeton d'au moins 1 024 caractères.
Composants/Rôles
  • L'utilisateur qui demande l'accès.
  • L'agent utilisateur où l'utilisateur s'authentifie, par exemple le navigateur Web.
  • Le fournisseur de services, c'est-à-dire l'application à laquelle l'utilisateur tente d'accéder.
  • Le fournisseur d'identité qui authentifie l'utilisateur.
  • L'utilisateur qui demande l'accès.
  • L'agent utilisateur où l'utilisateur s'authentifie, par exemple le navigateur Web.
  • La partie utilisatrice ou le client, c'est-à-dire l'application à laquelle l'utilisateur tente d'accéder.
  • Le fournisseur OpenID Connect, qui authentifie l'utilisateur et le client.

Connexion unique reposant sur SAML

Toute application Web requérant l'authentification de ses utilisateurs peut faire office de fournisseur de services. C'est elle qui utilise les informations renvoyées relatives à l'identité des utilisateurs.

Le fournisseur d'identité gère et produit une assertion de l'identité de l'utilisateur.

  1. L'utilisateur demande l'accès à une ressource protégée du fournisseur de services via un agent utilisateur.
  2. Le fournisseur de services envoie une demande d'authentification d'utilisateur en redirigeant l'agent utilisateur vers le fournisseur d'identité.
  3. Le fournisseur d'identité vérifie l'identité de l'utilisateur et génère une assertion « SAML » qui certifie l'identité de l'utilisateur.
  4. Le fournisseur d'identité intègre l'assertion dans sa réponse d'authentification « SAML » adressée au fournisseur de services.

Connexion unique reposant sur OpenID Connect

La partie connectée « OpenID » peut être n'importe quelle application qui exige que ses utilisateurs soient authentifiés. C'est elle qui utilise les informations renvoyées relatives à l'identité des utilisateurs.

Le fournisseur OpenID Connect authentifie l'utilisateur via son noeud final d'autorisation et authentifie le client via son noeud final de jeton.
  1. L'utilisateur demande l'accès à une ressource protégée de la partie utilisatrice par le biais d'un agent utilisateur.
  2. La partie utilisatrice envoie une demande d'authentification d'utilisateur en redirigeant l'agent utilisateur vers le fournisseur OpenID Connect.
  3. Le fournisseur OpenID Connect vérifie si l'utilisateur dispose d'une session valide. Sinon, le fournisseur OpenID Connect invite l'utilisateur à se connecter et authentifie l'utilisateur via le nœud final d'autorisation.
  4. Selon le type d'octroi d'autorisation, le noeud final d'autorisation du fournisseur d'identité peut envoyer une réponse d'authentification à la partie utilisatrice contenant :
    • Cette autorisation peut ensuite être transmise dans une requête par un client, accompagnée d'un code d'autorisation2 que la partie de confiance fournit à un point de terminaison de jetons en échange d'un jeton d'identité, d'un jeton d'accès ou d'un jeton de rafraîchissement.
    • Un jeton d'ID et un jeton d'accès.

      Le jeton d'ID ou le jeton d'actualisation contient les réclamations utilisateur et la signature qui sont utilisées pour établir la session utilisateur.

    • Un code Quick Response, un code utilisateur et une URL.
    • Flux implicite. Il procède à l'authentification et à l'autorisation en renvoyant directement un jeton d'identification et un jeton d'accès au client dans sa réponse.
    Remarque : le flux implicite du fournisseur « OpenID Connect » ne prend pas en charge le point de terminaison des jetons.
1 Ces affirmations concernent l'utilisateur; elles sont fiables si le destinataire du jeton peut vérifier sa signature. Elles sont destinées à fournir à l'application client des détails sur les utilisateurs autorisés tels que l'adresse électronique et le nom.
2 un certificat intermédiaire, qui contient les informations d'autorisation.