GNU/Linux >> Tutoriales Linux >  >> Linux

Introducción a los tokens autenticados cifrados

El servicio de identidad admite tokens de diferentes tipos y formatos para permitir que un usuario se autentique contra un servicio específico de Rackspace Technology Cloud.

  • El token tipo especifica si el usuario está aprovisionado o federado.
  • El formato del token especifica la composición del token en sí.

Identity ha cambiado el formato del token de autenticación de UUID a Cifrado autenticado (AE). Los ingenieros de Rackspace han implementado el nuevo formato de token en el backend del sistema Identity y el cambio tiene un impacto mínimo en los clientes de Rackspace. La diferencia principal es que el valor del token de autenticación devuelto por el servicio de identidad tiene un patrón y una longitud diferentes a los valores del token UUID emitidos anteriormente.

Nota: Asegúrese de seguir las mejores prácticas para manejar tokens de autenticación (que se encuentran más abajo en este artículo), especialmente si usa herramientas SDK o CLI para interactuar con RackspaceCloud.

Este artículo explica los dos formatos de token diferentes y brinda las mejores prácticas para trabajar con tokens de autenticación en general.

¿Qué es un token AE?

El uso del cifrado autenticado genera un token AE. El cifrado autenticado especifica una forma de asegurar un mensaje para que otros no puedan falsificarlo, cambiarlo o leerlo.

El cifrado autenticado genera no persistente tokens para la autenticación del usuario. Un token AE contiene todos los datos necesarios para determinar si un token determinado es válido en lugar de apuntar a estos datos. Los tokens AE tienen todos los metadatos cifrados dentro del propio token. Debido a que los tokens AE contienen todos los datos relevantes, no es necesario almacenar los tokens en un almacenamiento persistente. Cuando el servidor recibe el token, puede analizar los metadatos del token para determinar si es válido.

Debido al cifrado, el tamaño de un token con formato AE varía. El servicio de identidad limita el tamaño de los tokens con formato AE a 250 bytes.

El siguiente ejemplo muestra un objeto token de la respuesta de autenticación con un ID de token AE.

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

¿Qué es un token UUID?

Los tokens de autenticación que utilizan el formato de token UUID son persistentes fichas Cuando un usuario se autentica con éxito, el servicio de identidad genera un valor de token UUID de 32 caracteres y lo almacena en una unidad de almacenamiento persistente en el back-end. El servicio también guarda metadatos sobre ese token, como la marca de tiempo de caducidad, a quién se emite el token, etc. Luego, el servicio devuelve el valor del token al usuario, quien puede incluirlo en solicitudes posteriores a Rackspace Cloudservices para confirmar la identidad.

Cuando el usuario envía una solicitud con el token, el servicio de identidad valida el valor del token con los datos almacenados en el almacenamiento persistente para confirmar que el usuario está autorizado para realizar la operación. Cuando un token UUID caduca, el usuario debe volver a autenticarse. Luego, el servicio de identidad emite un nuevo token y también elimina el token caducado de la unidad de almacenamiento back-end persistente.

El siguiente ejemplo muestra un objeto de token de la respuesta de autenticación con una identificación de token UUID.

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

¿Cuál es la diferencia entre UUID y tokens AE?

Los tokens UUID y AE difieren en su persistencia, longitud y almacenamiento.

  • Los tokens UUID son persistentes . Los tokens AE son no persistentes . Con un token UUID, recibe un token cuando se autentica. Ese token persiste en el almacenamiento de back-end durante 24 horas y el sistema devuelve el mismo valor cada vez que se autentica hasta que el token caduca. Con AEtokens, el valor no es persistente, lo que significa que el valor no se almacena en el backend y el servicio de identidad genera y devuelve un nuevo valor de token cada vez que el usuario se autentica.
  • Los tokens UUID tienen 32 caracteres de longitud. Los tokens AE varían en tamaño, pero para el servicio de identidad tienen un límite de 250 bytes.2 Con la implementación de los tokens AE, notará que el valor del token devuelto cuando se autentica es significativamente más largo que el valor devuelto cuando el servicio de identidad emitió tokens UUID.
  • El sistema almacena los tokens UUID en el back-end del servicio de identidad con los metadatos para la autenticación. Los tokens AE proporcionan los metadatos de autenticación requeridos dentro del valor del token cifrado. El servicio de identidad no almacena el valor del token AE en el sistema de back-end.

Mejores prácticas para manejar tokens de autenticación

Las siguientes son algunas de las mejores prácticas para manejar tokens de autenticación.

  • Cuando se autentique en el servicio de identidad, asegúrese de almacenar en caché el valor del token devuelto.

    El servicio de identidad valida el token de autenticación en cada solicitud de API antes de intentar completar la operación. Para optimizar las operaciones de la API y reducir la carga del sistema, almacene el token de autenticación en una caché o base de datos segura para que las aplicaciones puedan usar el valor almacenado en lugar de requerir que la aplicación emita una solicitud de autenticación antes de cada operación de la API. Puede reutilizar el valor del token almacenado en caché siempre que siga siendo válido.

    Nota: Para ver un ejemplo de almacenamiento en caché de credenciales con un SDK, consulte Almacenamiento en caché de credenciales en la documentación de php-opencloud.

  • Diseñe aplicaciones para volver a autenticarse después de recibir un 401 Unauthorized Respuesta {.code} de un punto final de servicio o para verificar el vencimiento del token y volver a autenticarse antes de que expire el token.

  • Para simplificar la administración de autenticación, credenciales y tokens, utilice una aplicación cliente de línea de comandos de OpenStack.

Para obtener más información, lea la sección Administrar tokens de autenticación en la Guía de Identity API 2.0.

Use la pestaña Comentarios para hacer cualquier comentario o hacer preguntas. También puede iniciar una conversación con nosotros.


Linux
  1. Una introducción a las utilidades principales de GNU

  2. Lenguaje de programación C - Introducción

  3. Una introducción al comando diff

  4. Introducción a Docker

  5. Borrado de emergencia SSD

Una introducción al navegador Vivaldi en Linux

Introducción a la gestión de contenedores de Linux

Almacenar archivos en una imagen cifrada

Introducción a la plataforma de automatización de Ansible

Una introducción a los hechos de Ansible

vSphere vMotion cifrado