GNU/Linux >> Tutoriels Linux >  >> Linux

Introduction aux jetons authentifiés chiffrés

Le service d'identité prend en charge les jetons de différents types et formats pour permettre à un utilisateur de s'authentifier auprès d'un service Rackspace Technology Cloud spécifique.

  • Le jeton type spécifie si l'utilisateur est provisionné ou fédéré.
  • Le format du jeton spécifie la composition du jeton lui-même.

Identity a changé le format du jeton d'authentification d'UUID en chiffrement authentifié (AE). Les ingénieurs de Rackspace ont implémenté le nouveau format de jeton sur le backend du système d'identité, et le changement a un impact minimal sur les clients de Rackspace. La principale différence est que la valeur du jeton d'authentification renvoyée par le service d'identité a un modèle et une longueur différents des valeurs de jeton UUID émises précédemment.

Remarque : Assurez-vous de suivre les meilleures pratiques de gestion des jetons d'authentification (situées plus loin dans cet article), en particulier si vous utilisez des outils SDK ou CLI pour interagir avec le RackspaceCloud.

Cet article explique les deux formats de jeton différents et fournit les meilleures pratiques pour travailler avec les jetons d'authentification en général.

Qu'est-ce qu'un jeton AE ?

L'utilisation du cryptage authentifié génère un jeton AE. Le cryptage authentifié spécifie un moyen de sécuriser un message afin que d'autres ne puissent pas le falsifier, le modifier ou le lire.

Le chiffrement authentifié génère non persistant jetons pour l'authentification des utilisateurs. Un jeton AE contient toutes les données nécessaires pour déterminer si un jeton donné est valide au lieu de pointer vers ces données. Les jetons AE contiennent toutes les métadonnées chiffrées dans le jeton lui-même. Étant donné que les jetons AE contiennent toutes les données pertinentes, il n'est pas nécessaire de stocker les jetons dans un stockage persistant. Lorsque le serveur reçoit le jeton, il peut analyser les métadonnées du jeton pour déterminer s'il est valide.

En raison du cryptage, la taille d'un jeton au format AE varie. Le service Identity limite la taille des jetons au format AE à 250 octets.

L'exemple suivant montre un objet jeton de la réponse d'authentification avec un ID de jeton AE.

"token": {
      "id": "ABCDEF7RbnU-LLWJ1J8PeHRGMz2Cf3rPUG_a25hQRWTcL7tH231H7ubr6y1EkRi_curq6PqJV-pCiIADZrwFtCexcy9MVO3eckgGWqDqnxvXaUMF7XA_reFwwp3pNu_7p9uXofGmiueccwrA",
      "expires": "2015-08-20T23:51:19.055Z",
       "tenant": {
       "id": "123456",
       "name": "123456"
         }

Qu'est-ce qu'un jeton UUID ?

Les jetons d'authentification qui utilisent le format de jeton UUID sont persistants jetons. Lorsqu'un utilisateur s'authentifie avec succès, le service Identity génère une valeur de jeton UUID de 32 caractères et la stocke dans une unité de stockage persistante sur le back-end. Le service enregistre également des métadonnées sur ce jeton, telles que l'horodatage d'expiration, à qui le jeton est émis, etc. Ensuite, le service renvoie la valeur du jeton à l'utilisateur, qui peut l'inclure dans les demandes ultérieures aux services Rackspace Cloud pour confirmer l'identité.

Lorsque l'utilisateur soumet une demande avec le jeton, le service d'identité valide la valeur du jeton par rapport aux données stockées dans le stockage persistant pour confirmer que l'utilisateur est autorisé à effectuer l'opération. Lorsqu'un jeton UUID expire, l'utilisateur doit se ré-authentifier. Ensuite, le service d'identité émet un nouveau jeton et supprime également le jeton expiré de l'unité de stockage principale persistante.

L'exemple suivant montre un objet jeton de la réponse d'authentification avec un identifiant de jeton UUID.

"token": {
      "id": "b726839ca0fd4d9ead8edbb73f123456",
      "expires": "2015-08-20T23:48:50.793Z",
      "tenant": {
      "id": "123456",
      "name": "123456"
         }

Quelle est la différence entre les jetons UUID et AE ?

Les jetons UUID et AE diffèrent par leur persistance, leur longueur et leur stockage.

  • Les jetons UUID sont persistants . Les jetons AE sont non persistants . Avec un jeton UUID, vous recevez un jeton lorsque vous vous authentifiez. Ce jeton persiste dans le stockage principal pendant 24 heures et le système renvoie la même valeur chaque fois que vous vous authentifiez jusqu'à l'expiration du jeton. Avec les AEtokens, la valeur n'est pas persistante, ce qui signifie que la valeur n'est pas stockée sur le backend, et le service d'identité génère et renvoie une nouvelle valeur de jeton chaque fois que l'utilisateur s'authentifie.
  • Les jetons UUID comportent 32 caractères. Les jetons AE varient en taille, mais pour le service Identity, ils ont une limite de 250 octets. /li>
  • Le système stocke les jetons UUID dans le back-end du service d'identité avec les métadonnées pour l'authentification. Les jetons AE fournissent les métadonnées d'authentification requises dans la valeur du jeton chiffré. Le service Identity ne stocke pas la valeur du jeton AE dans le système back-end.

Meilleures pratiques pour la gestion des jetons d'authentification

Voici quelques bonnes pratiques pour gérer les jetons d'authentification.

  • Lorsque vous vous authentifiez auprès du service d'identité, veillez à mettre en cache la valeur de jeton renvoyée.

    Le service d'identité valide le jeton d'authentification dans chaque demande d'API avant de tenter de terminer l'opération. Pour optimiser vos opérations d'API et réduire la charge du système, stockez le jeton d'authentification dans un cache sécurisé ou une base de données afin que les applications puissent utiliser la valeur stockée au lieu d'exiger que l'application émette une demande d'authentification avant chaque opération d'API. Vous pouvez réutiliser la valeur du jeton mis en cache tant qu'elle reste valide.

    Remarque : Pour un exemple de mise en cache des informations d'identification avec un SDK, consultez Mise en cache des informations d'identification dans la documentation php-opencloud.

  • Concevoir des applications pour se réauthentifier après avoir reçu un 401 Unauthorized {.code} réponse d'un point de terminaison de service ou pour vérifier l'expiration du jeton et réauthentifier avant que le jeton n'expire.

  • Pour simplifier la gestion de l'authentification, des informations d'identification et des jetons, utilisez une application cliente en ligne de commande OpenStack.

Pour plus d'informations, lisez la section Gérer les jetons d'authentification dans le guide Identity API 2.0.

Utilisez l'onglet Commentaires pour faire des commentaires ou poser des questions. Vous pouvez également démarrer une conversation avec nous.


Linux
  1. Introduction aux outils automatiques GNU

  2. Une introduction aux utilitaires GNU Core

  3. Introduction à Nmap sur Kali Linux

  4. Une introduction à la commande diff

  5. Essuyage d'urgence SSD

Une introduction au navigateur Vivaldi sous Linux

Introduction à la gestion des conteneurs Linux

Stocker des fichiers dans une image cryptée

Introduction à la plate-forme d'automatisation Ansible

Une introduction aux faits Ansible

vSphere vMotion chiffré