Logotipo de Zephyrnet

Tokens y sesiones de inicio de sesión en IBM Cloud – Blog de IBM

Fecha:


Calle arbolada

La autenticación y autorización de IBM Cloud se basa en el protocolo estándar del sector OAuth 2.0. Puede leer más sobre OAuth 2.0 en RFC 6749—El marco de autorización OAuth 2.0. Como la mayoría de los que adoptan OAuth 2.0, IBM también ha ampliado algunas de las funciones de OAuth 2.0 para cumplir con los requisitos de IBM Cloud y sus clientes.

Acceder y actualizar tokens

Como se especifica en RFC 6749, las aplicaciones obtienen un token de acceso para representar la identidad que se ha autenticado y sus permisos. Además, en IBM Cloud, el token de acceso también representa la cuenta actual seleccionada. Cuando las aplicaciones invocan IBM Cloud Services, este token de acceso se transmite como parte de la llamada API como encabezado de autorización HTTP para proporcionar información sobre la persona que llama. El IBM Cloud Service de destino tomará su decisión de autorización en función del contenido del token de acceso:

Figura 1: La clave API se intercambia por un token de acceso de IAM, que luego se utiliza para llamar a un servicio.

Para casos de uso específicos, las aplicaciones también pueden recuperar tokens de actualización de IAM. De esta manera, las aplicaciones pueden recuperar un nuevo token de acceso cuando caduque el anterior. Esto es importante para IBM Cloud Console o IBM Cloud CLI, por ejemplo, porque de lo contrario, el usuario final tendría que iniciar sesión nuevamente después de que caduque el token de acceso (es decir, después de al menos 60 minutos o incluso antes). Los tokens de actualización deben almacenarse en un lugar seguro y, aun así, eventualmente caducan. 

Las aplicaciones de cliente en IBM Cloud tienen dos formas de crear un token de acceso para poder invocar los servicios de IBM Cloud:

1. Utilice una clave API para obtener un token de acceso (ver aquí para más información):

Figura 2: Intercambio de una clave API de IAM por un token de acceso.

2. Obtenga un token de acceso cuando se ejecute en una plataforma informática gestionada por IBM Cloud. Para obtener instrucciones sobre cómo hacerlo, consulte los siguientes blogs:

Figura 3: Intercambio de un token de recursos informáticos por un token de acceso.

En ambos casos, la aplicación tiene acceso a la clave API o al token de recursos informáticos desde la plataforma informática gestionada por IBM Cloud de todos modos. Por lo tanto, no hay ningún beneficio en que la aplicación almacene y utilice el token de actualización. Cuando la aplicación requiere un nuevo token de acceso, puede usar la clave API o el token de recurso informático nuevamente. Por lo tanto, IBM Cloud IAM no generará tokens de actualización para esos casos de uso.

Formato de token

IBM Cloud está diseñado para escalar. Por lo tanto, los tokens de acceso en IBM Cloud utilizan el formato JSON Web Token (consulte también RFC 7519). Los tokens web JSON tienen un formato estándar:

Figura 4: Formato de un token web JSON estándar.

La firma de los tokens de acceso de IBM Cloud se crea utilizando el algoritmo asimétrico RS256. Esto significa que solo IBM Cloud IAM puede firmar esos tokens de acceso, pero cualquier servicio IBM Cloud (e incluso aplicaciones de terceros) puede verificar la validez de una firma de token utilizando la parte pública de la clave de firma. IBM Cloud IAM anuncia la parte pública de las claves de firma actualmente válidas esta página.

Figura 5: Ejemplo de salida del punto final de claves.

IBM Cloud Services y otras aplicaciones deben descargar y almacenar en caché esas claves durante una hora. Usando esas claves de firma públicas, ahora pueden validar la firma de esos tokens. De esta manera, los servicios de nube de IBM y las API pueden validar esos tokens sin ninguna latencia relevante. No necesitan llamar a IAM para cada token de acceso para verificar su validez. Este método se escala muy bien, ya que la carga de validación aumenta con cada API y servicio de nube de IBM. Como consecuencia, esos tokens de acceso no se pueden revocar; una revocación requeriría que cada adoptante verificara el token de acceso con IAM. Una llamada de este tipo a IAM destruiría todas las ventajas descritas anteriormente.

Los tokens de actualización no siguen ningún formato documentado. Solo IBM Cloud IAM puede crearlos y comprenderlos. Para obtener un nuevo token de acceso para un token de actualización, es necesario enviar el token de actualización a IAM. Luego, IAM validará el token de actualización y su entidad relacionada y creará un token de acceso si las distintas validaciones son exitosas. Esto significa que un token de actualización no podrá crear un nuevo token de acceso si, por ejemplo, el usuario relacionado se eliminó de IBMid o el ID de servicio relacionado ya no existe.

sesiones de inicio de sesión

Una sesión de inicio de sesión se crea en el momento en que un usuario final inicia sesión en Consola de nube de IBM O al Cliente de interfaz de línea de comandos (CLI) de IBM Cloud. Un usuario puede ver y administrar sesiones de inicio de sesión. usando la interfaz. El usuario puede finalizar sesiones de inicio de sesión individuales utilizando esta interfaz de usuario u obtener una descripción general de las sesiones de inicio de sesión. De esta forma, el usuario puede revisar y revocar sus sesiones de inicio de sesión:

Figura 6: Descripción general de la sesión de inicio de sesión.

Una sesión de inicio de sesión finalizará si ocurre uno de los siguientes eventos:

  • La sesión de inicio de sesión está caducando (24 horas de forma predeterminada)
  • La sesión de inicio de sesión no se utilizó activamente durante un tiempo predefinido (dos horas, de forma predeterminada)
  • Un usuario cierra manualmente una sesión de inicio de sesión o revoca una sesión de inicio de sesión
  • Se han abierto demasiadas sesiones de inicio de sesión (sin límite, de forma predeterminada)
Figura 7: La sesión de inicio de sesión caduca después de 24 horas.
Figura 8: La sesión de inicio de sesión se vuelve inactiva después de dos horas sin ver ninguna actividad.
Figura 9: La sesión de inicio de sesión se revoca cuando un usuario presiona el botón de cerrar sesión o revocar.

Configurar los ajustes de la sesión de inicio de sesión

El administrador de IAM de una cuenta de IBM Cloud puede configurar ciertos parámetros para las sesiones de inicio de sesión:

  • Sesiones activas: Vida útil máxima de una única sesión de inicio de sesión. Una vez superada esta vida útil, la sesión de inicio de sesión se marca como caducada. Puede iniciar una nueva sesión ingresando nuevamente las credenciales de inicio de sesión. El valor predeterminado es 24 horas. Los administradores de IAM pueden ampliar esta duración hasta 720 horas o reducirla a 15 minutos. La Figura 7 anterior describe un escenario en el que se ha excedido la vida útil predeterminada de 24 horas.
  • Cerrar sesión por inactividad: Una sesión de inicio de sesión se marca como activa según la interacción de la aplicación con IAM. Por ejemplo, el uso de un token de actualización restablece el temporizador de inactividad. Un administrador de IAM puede establecer el valor para detectar inactividad en al menos 15 minutos o como máximo 24 horas. De forma predeterminada, se utilizan dos horas. La Figura 8 anterior describe este escenario y finaliza la sesión de inicio de sesión después de dos horas de inactividad.
  • Sesiones concurrentes: De forma predeterminada, puede crear un número ilimitado de sesiones de inicio de sesión. Puede haber razones para limitar la cantidad máxima de sesiones de inicio de sesión (por ejemplo, para limitar la cantidad de scripts que se ejecutan en paralelo para un usuario determinado). Para este escenario, puede establecer un límite de sesiones simultáneas. Si una nueva sesión de inicio de sesión amplía el límite de sesiones simultáneas, se revoca la sesión en ejecución más antigua. El estado de la sesión es el mismo que si se hubiera revocado manualmente como se describe en la Figura 9.

Los ajustes de configuración para los tokens de acceso y los tokens de actualización en la sección Caducidad del token no están relacionados con los tokens que se crean para las sesiones de inicio de sesión. Estas configuraciones controlan el comportamiento de los tokens que existen sin una sesión de inicio de sesión conectada. Encontrarás más detalles más adelante en este blog.

Sesiones de inicio de sesión y tokens

Como se explicó anteriormente, IBM Cloud Console y IBM Cloud CLI funcionan internamente con tokens de acceso y actualización para poder invocar IBM Cloud Services y las API de IBM Cloud. IBM Cloud combina la seguridad del modelo OAuth 2.0 con las capacidades de gestión de sesiones de inicio de sesión.

Para el momento del inicio de sesión, la aplicación que llama (por ejemplo, IBM Cloud Console) obtiene un token de acceso y un token de actualización de IAM. En segundo plano, IAM inicia una sesión de inicio de sesión y conecta el token de acceso y actualización con la sesión de inicio de sesión. Como los tokens de acceso no se pueden revocar, su vida útil está limitada a 20 minutos o menos.

Siempre que el token de acceso caduque, la aplicación que realiza la llamada debe utilizar el token de actualización para obtener un nuevo token de acceso. La sesión tiene un temporizador de inactividad que se inicia en el momento del inicio de sesión y se reinicia cada vez que se detecta una actividad (por ejemplo, una operación de token de actualización). La sesión finaliza si se revoca activamente, se cumple el vencimiento general de la sesión o la sesión detecta inactividad. Todos los tokens de actualización dejan de funcionar si finaliza la sesión.

Figura 10: Relación entre sesión de inicio de sesión, token de acceso y token de actualización.

Tokens sin sesiones de inicio de sesión

Crear y mantener sesiones de inicio de sesión es una operación que requiere un uso intensivo de computación. Por lo tanto, IBM Cloud no puede crear una sesión de inicio de sesión para cada interacción. Especialmente para las invocaciones de servicios, a menudo no hay necesidad de iniciar sesión ni de la capacidad de revocar sesiones o actualizar tokens (si se eligen tiempos de vida razonables).

Tokens de acceso sin tokens de actualización

Si, como se describe al principio de este blog, crea un token de acceso usando una clave API o recupera un token de acceso basado en su plataforma informática, no necesita usar un token de actualización. Siempre puede crear un token de acceso nuevo utilizando la clave API o basándose en el token de recursos informáticos que proporciona la plataforma informática. Por lo tanto, IBM Cloud IAM no generará un token de actualización en esos escenarios. Además, no creará una sesión de inicio de sesión en segundo plano.

Acceda y actualice tokens sin iniciar sesión

Si inicia sesión en la CLI de IBM Cloud utilizando una clave API que representa un ID de servicio, esta interacción no creará una sesión de inicio de sesión. Sin embargo, la CLI espera ejecutarse más tiempo del que tarda un token de acceso en caducar, por lo que la CLI requerirá un token de actualización. IBM Cloud IAM creará un token de acceso y actualización que no estará conectado a una sesión de inicio de sesión.

Por lo general, se espera que esos tokens se utilicen dentro de una CLI únicamente y, por lo tanto, en un entorno que tenga una protección razonable contra el uso indebido.

Configurar la caducidad del token

La configuración de IAM le permite configurar la vida útil de los tokens de acceso y de actualización que no tienen una sesión de inicio de sesión relacionada:

  • Fichas de acceso: La vida útil de los tokens de acceso creados dentro de esta cuenta es independiente de las sesiones de inicio de sesión. El valor predeterminado es 60 minutos. Esto significa que si está creando un token de acceso para una clave API, de forma predeterminada, recuperará un token de acceso que IBM Cloud Services considera válido durante los próximos 60 minutos. Si desea limitar la vida útil de los tokens de acceso, puede elegir un valor menor. Considere elegir un valor que aún le permita ejecutar todos los servicios de nube de IBM necesarios. Algunas operaciones de ejecución más prolongada, como la búsqueda con el motor de datos dentro de los depósitos de COS, podrían dejar de funcionar.
  • Actualizar fichas: De forma predeterminada, los tokens de actualización son válidos por hasta 72 horas. Esto significa que si inició sesión en la CLI de IBM Cloud con una clave API para un ID de servicio, esta CLI de IBM Cloud puede continuar funcionando durante las próximas 72 horas, ya que puede actualizar el token de acceso cuando sea necesario. Si su cuenta no tiene tal requisito, puede reducir la vida útil de los tokens de actualización a un valor menor. Tenga en cuenta que esto limita el tiempo máximo de ejecución para servicios de larga duración que utilizan un token de actualización para continuar. Nuevamente, esta configuración solo se aplica a los tokens de actualización que se crean independientemente de las sesiones de inicio de sesión.

Resumen

IBM Cloud IAM utiliza tokens de acceso para permitir a los clientes llamar a IBM Cloud Services. Para las interacciones de API, IBM Cloud IAM evita tener que generar tokens de actualización tanto como sea posible. Una excepción a esa regla es el uso de ID de servicio para operaciones de CLI de IBM Cloud. Para permitir también interacciones de larga duración con IBM Cloud que van más allá de la vida útil de un token de acceso, IBM Cloud IAM ofrece sesiones de inicio de sesión que brindan al usuario final control sobre la caducidad y la revocación de la sesión.

Revise la configuración de IAM para ver si se ajusta a sus necesidades:

Figura 11: Configuración de IAM relacionada con tokens y sesiones de inicio de sesión.

Recuerde que las dos configuraciones de vencimiento para los tokens de acceso y actualización en la sección Caducidad del token solo se relacionan con interacciones de API y sesiones de ID de servicio dentro de la CLI de IBM Cloud. Las sesiones de usuario normales en IBM Cloud Console o aplicaciones similares crearán una Sesión de inicio de sesión. La caducidad de los tokens de acceso y los tokens de actualización están influenciadas indirectamente por los parámetros de configuración de la sesión en Sesión de inicio de sesión.

Para obtener más información, consulte estos recursos:


Más de la nube




Ejemplos, aplicaciones y casos de uso de la nube híbrida

7 min leerPara mantenerse al día con el entorno dinámico de los negocios impulsados ​​digitalmente, las organizaciones continúan adoptando la nube híbrida, que combina y unifica la nube pública, la nube privada y la infraestructura local, al tiempo que proporciona orquestación, gestión y portabilidad de aplicaciones en las tres. Según IBM Transformation Index: State of Cloud, una encuesta de 2022 encargada por IBM y realizada por una firma de investigación independiente, más del 77% de las empresas y profesionales de TI dicen haber adoptado un enfoque de nube híbrida. Creando una plataforma ágil, flexible y...




Cómo pasar de IBM Cloud Functions a IBM Code Engine

5 min leerAl migrar desde IBM Cloud Functions, IBM Cloud Code Engine es uno de los posibles objetivos de implementación. Code Engine ofrece aplicaciones, trabajos y (funciones recientes) entre las que puede (o necesita) elegir. En esta publicación, proporcionamos algunos puntos de discusión y compartimos consejos y trucos sobre cómo trabajar con las funciones de Code Engine. IBM Cloud Code Engine es una plataforma sin servidor totalmente gestionada para (no solo) ejecutar sus cargas de trabajo en contenedores. Ha evolucionado mucho desde marzo de 2021, cuando…




Sensores, señales y sinergia: mejorando la exploración de datos de Downer con IBM

3 min leerEn el ámbito del transporte urbano, la precisión es fundamental. Downer, un proveedor líder de servicios integrados en Australia y Nueva Zelanda, se considera un guardián de la elaborada matriz de transporte y busca continuamente mejorar su eficiencia operativa. Con más de 200 trenes y multitud de sensores, Downer ha acumulado una gran cantidad de datos. Si bien Downer descubre periódicamente información útil a partir de sus datos, su asociación con IBM® Client Engineering tenía como objetivo explorar el potencial adicional de este vasto conjunto de datos,...




Mejores prácticas para una implementación segura y compatible de aplicaciones bancarias en la nube híbrida en IBM Cloud y Satellite

10 min leerLos clientes de servicios financieros buscan cada vez más modernizar sus aplicaciones. Esto incluye la modernización del desarrollo y mantenimiento del código (ayudando con habilidades escasas y permitiendo la innovación y nuevas tecnologías requeridas por los usuarios finales), así como la mejora del despliegue y las operaciones, utilizando técnicas ágiles y DevSecOps. Como parte de su viaje de modernización, los clientes quieren tener flexibilidad para determinar cuál es la mejor ubicación de implementación "adecuada para su propósito" para sus aplicaciones. Esto puede ser en cualquiera de los entornos que Hybrid...

Boletines informativos de IBM

Obtenga nuestros boletines y actualizaciones de temas que brindan el liderazgo intelectual más reciente y conocimientos sobre tendencias emergentes.

Subscribirme Ahora

Más boletines

punto_img

Información más reciente

punto_img