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 utiliser Verify pour l'authentification et l'autorisation des utilisateurs. Les utilisateurs se connectent aux applications cible à l'aide de leurs données d'identification de compte Verify . Lorsqu'ils sont authentifiés auprès d' Verify, les utilisateurs peuvent accéder à toutes les applications auxquelles ils ont droit, dans la session authentifiée. A l'expiration de la session, les utilisateurs doivent se reconnecter via Verify.

Pour implémenter la connexion unique entre Verify et toute application cible, ils doivent échanger les détails 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 à l'aide de SAML et d' OpenID Connect.
Tableau 1. Résumé comparatif
langage SAML OpenID Connect
Descriptif

Security Assertion Markup Language (SAML) est une norme ouverte qui fournit 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 de norme ouverte qui combine l'authentification OpenID et les fonctions 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 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'ID.

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 réclamations utilisateur (informations sur 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 de jeton OAuth/OIDC ne sont pas fixes. Lors du stockage des jetons d'accès et d'actualisation, autorisez 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 dans le futur, autorisez au moins 1024 caractères pour la longueur du jeton.
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 affirme l'identité de l'utilisateur.
  4. Le fournisseur d'identité conditionne l'assertion dans sa réponse d'authentification SAML au fournisseur de services.

Connexion unique reposant sur OpenID Connect

La partie utilisatrice OpenID Connect peut être n'importe quelle application qui requiert l'authentification de ses utilisateurs. 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 demande par un client, avec un code d'autorisation2 que la partie utilisatrice fournit à un noeud final de jeton en échange d'un jeton d'ID, d'un jeton d'accès ou d'un jeton d'actualisation.
    • 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 effectue l'authentification et l'autorisation en renvoyant directement un jeton d'ID et un jeton d'accès au client dans sa réponse.
    Remarque: OpenID Connect Le flux implicite ne prend pas en charge le noeud final de jeton.
1 Ces réclamations sont des instructions concernant l'utilisateur, qui peuvent être sécurisées si le consommateur 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 droit d'accès intermédiaire, qui code l'autorisation.