Totvs Clock In - Espanhol

Árvore de páginas

01. VISIÓN GENERAL


Esta documentación le va a orientar al paso a paso de validaciones/configuraciones previas en su entorno delCLOCK IN que deben realizarse antes de habilitar el acceso al CLOCK IN utilizando el SSO (Single Sign-On) del Azure Active Directory o Totvs Identity (Fluig) como proveedores de identidad (IDP).


02. CREACIÓN DE USUARIOS PARA CORRESPONDENCIA DE CUENTAS


  • Usuarios creados automáticamente o por medio del CLOCK IN BACKOFFICE deben tener una cuenta/e-mail correspondiente en el IdP-proveedor de identidad homologado, ya sea Azure o Totvs Identity. Es decir, si el usuario creado en el CLOCK IN fuera [email protected], también debe ser exactamente [email protected] IdP-proveedor de identidad homologado, ya sea Azure o Totvs Identity (Fluig).
  • Cuentas que no tengan esta correspondencia no podrán acceder más a las aplicaciones del CLOCK IN, o si existieran en el IdP y no en el entorno del CLOCK IN, no tendrán sus parámetros de entorno actualizados (configuración de DAL, GEOFENCE, SELF CLOCK IN, etc.).


Para más detalles acceda a nuestro artículo: 3. Creación automática de usuarios

Acceda a los Settings del Backoffice, vaya hasta la cesión de Usuarios - Creación automática y verifique cuál es la Regla de login utilizada. Esta regla es impuesta a todo registro de Empleado del Backoffice.


Si la creación automática se basara en el e-mail del registro del empleado, es importante que sea exactamente del registro del Azure o Totvs Identity (Fluig).

Ejemplo Azure:

Ejemplo Totvs Identity (Fluig):


Si utilizara cualquier otra regla de Login, es importante realizar la misma validación. E-mails FALSOS/FAKE, creados a partir de la matrícula u otros, que se utilicen para Login en el CLOCK IN dejarán de funcionar, a menos que incluyan estos también el Azure o Fluig.

Para más detalles acceda a nuestro artículo: 2. Registro de usuarios

En el caso de usuarios genéricos para tabletas y otros, el procedimiento se mantiene el mismo, su creación debe realizarse exclusivamente por medio del Backoffice, sin embargo el LOGIN utilizado también debe existir y ser exactamente igual en el Azure o Totvs Identity (Fluig).

Los usuarios que estuvieran conectados al CLOCK IN MOBILE antes de habilitar el SSO permanecerán conectados hasta que el TOKEN de autenticación sea revocado, aunque este usuario no tenga vínculo con ningún usuario del IdP-proveedor de identidad.

La aplicación CLOCK IN MOBILE utiliza el login por SSO o email/contraseña solamente como si fuera una puerta de entrada para generación de un TOKEN.

Este TOKEN se utiliza para generar lo que llamamos API Key y esta se utiliza para comunicarse con la Plataforma Carol en otras requisiciones, como el envío de registros realizados por medio del app CLOCK IN MOBILE. La API Key solamente va a expirar si fuera revocada o el usuario fuera desactivado/retirado.

Resumiendo, el token generado por la IdP-proveedor de identidad se utiliza solamente para que validemos la entrada y obtengamos el API Key. Una vez que tenga el API Key, este no va a expirar.


Estos usuarios perderán el acceso al entorno y a las aplicaciones, pero permanecerán activos internamente en la Plataforma Carol, quedando a criterio del cliente desactivarlos por medio del Backoffice.

03. ¿POR QUÉ CREAR USUARIOS EN EL CLOCK IN SI EL ACCESO ES VÍA AZURE/TOTVS IDENTITY?

 

  • Todo usuario debe estar vinculado a un Tenant/Entorno dentro de la Plataforma Carol para que consiga realizar el Login en la aplicación del Clock In Mobile, Clock In Web y/o Backoffice;
  • Toda parte de seguridad de acceso de la Plataforma Carol y del Clock In están vinculadas al Grupo de acceso de los usuarios. Para más detalles acceda a nuestro artículo: Configuración del Data Access Level (Privacidad de datos) o 2. Data Access Level (DAL);
  • Los parámetros de entorno utilizados por el Clock In Mobile, Clock In Web y/o Backoffice quedan vinculados al usuario. Estos parámetros de entorno se utilizan para el Data Access Level, para definir si aquel usuario va a utilizar la Cerca virtual a nivel y Local y/o Empresa, si este tendrá acceso o no al Backoffice, si este tendrá acceso o no a la Interfaz de usuario de la Plataforma Carol, entre otras features del producto.

04. DESACTIVACIÓN DE USUARIOS EXISTENTES ANTES DE HABILITAR EL AZURE/TOTVS IDENTITY


Cuando existen usuarios previamente creados en el CLOCK IN que no tienen correspondencia en el proveedor de identidad (IdP) habilitado, como Azure AD o Totvs Identity, es necesario desactivarlos manualmente para evitar problemas de acceso. Esta desactivación puede realizarse directamente en el Backoffice.

Para desactivar un usuario individualmente, siga estos pasos:

  1. Acceda a Backoffice > Usuarios.
  2. Ubique el usuario deseado.
  3. Seleccione el usuario y proceda con la desactivación.

Es importante garantizar que solamente usuarios que no tienen correspondencia en el IdP se desactiven, para evitar interrupciones de acceso indebidas.




05. DESACTIVACIÓN COLECTIVA DE USUARIOS ANTES DE HABILITAR EL AZURE/TOTVS IDENTITY


Cuando existe un gran número de usuarios sin correspondencia en el proveedor de identidad y entienda que la desactivación manual es inviable y/o para realizar la desactivación de varios usuarios simultáneamente, es necesario involucrar al equipo de servicios.

En este caso, entre en contacto con la ESN y solicite una propuesta de servicios para la desactivación colectiva de los usuarios.