Árvore de páginas

01. VISIÓN GENERAL


Esta documentación tiene como objetivo mostrar los impactos de la habilitación y utilización del IdP/SSO en el Clock In.


02. IMPACTOS DE LA HABILITACIÓN DEL IdP/SSO


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).

02.1 DESHABILITACIÓN DEL LOGIN TRADICIONAL

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.


  • Login vía Plataforma Carol:



  • Login vía idP/SSO



02.2 SESIONES ACTIVAS 

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.

02.3 CORRESPONDENCIA DE CUENTAS 

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.



02.4 EXCLUSIVIDAD IdP/SSO


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.


03. CONSIDERACIONES FINALES

  • Configuración en el Proveedor de identidad: La configuración inicial es realizada por el cliente en su entorno del IdP-proveedor de identidad (Azure Totvs Identity), donde es necesario crear la aplicación y realizar las configuraciones de seguridad.
  • Envío de las informaciones: Después de la configuración en el IdP-proveedor de identidad, las informaciones deben enviarse al equipo de Implantación o por medio de Ticket al equipo de atención del CLOCK IN, que realizará la integración y habilitará el SSO en el entorno del CLOCK IN.
  • Validez de los E-mails: No se permitirán e-mails falsos registrados en el Clock In. Solamente usuarios con e-mails válidos y configurados en el IdP-proveedor de identidad podrán acceder a la plataforma.
  • MDM Intune: La utilización Azure integrado con el MDM Intune en los dispositivos no está funcionamiento en este momento. Cuando finalice la implementación para atender la integración con los dos productos informaremos aquí en la documentación.