Esta documentación tiene como objetivo mostrar los impactos de la habilitación y utilización del IdP/SSO en el Clock In.
Al habilitar el IdP/SSO, el login tradicional por la plataforma se deshabilitará, es decir, el flujo de autenticación tanto de la Plataforma Carol como de las aplicaciones del Clock In ocurrirá por el proveedor de identidad (Azure Active Directory o Totvs Identity (Fluig)) sin posibilidad de separación entre las aplicaciones (BackOffice, Clock in Web y/o Clock In Mobile).
Después de la habilitación del IdP/SSO, el login anterior vía Plataforma Carol será desactivado. Todos los usuarios deben utilizar el SSO para acceder a las aplicaciones del Clock In.
Los usuarios que estuvieran conectados a la Aplicación Mobile antes de habilitar el Idp/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/SSO.
La aplicación Mobile utiliza el login por SSO o email/contraseña solamente como si fuera una puerta de entrada para la generación de un TOKEN.
Este "token" se utiliza para generar lo que llamamos API Key y está se utiliza para comunicarse con la Plataforma Carol en otras requisiciones, como el envío de registros realizados por medio del app. La API Key solamente va a expirar si se revocara o si el usuario fuera desactivado/retirado.
Resumiendo, el "token" generado por la IdP/SSO 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.
Usuarios creados automáticamente o por medio del BackOffice deben tener una cuenta/e-mail correspondiente en el IdP-proveedor de identidad homologado, ya sea Azure o Totvs Identity. Cuentas que no tengan esta correspondencia no podrán acceder más a las aplicaciones del CLOCK IN, o si existieran el IdP y en el entorno del CLOCK IN, no tendrán sus parámetros de entorno actualizados (configuración de DAL, GEOFENCE, SELF CLOCK IN, etc.). Haga clic aquí para más informaciones sobre los usuarios del CLOCK IN.
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.
Ejemplo consultando el usuario en la Plataforma Carol con parámetros de entorno del CLOCK IN.
Ejemplo consultando el usuario en el TOTVS IDENTITY (Fluig).
Ejemplo consultando el usuario en el AZURE.
No es posible utilizar el login tradicional en conjunto con el SSO. Una vez que el SSO esté habilitado, este será el único método de autenticación disponible y la Plataforma Carol realizará automáticamente la orientación al IdP-proveedor de identidad homologado.