Histórico da Página
| Índice |
|---|
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
...
Esta documentação vai lhe direcionar para o passo a passo de validações/configurações prévias em seu ambiente do CLOCK IN que devem ser realizadas antes de habilitar o acesso ao CLOCK IN usando o SSO (Single Sign-On) do del Azure Active Directory ou Directory o Totvs Identity (Fluig) como provedores de identidade 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
...
- Usuários criados automaticamente ou através do CLOCK IN BACKOFFICE devem ter uma conta/e-mail correspondente no correspondiente en el IdP-provedor de identidade homologado, seja Azure ou proveedor de identidad homologado, ya sea Azure o Totvs Identity. Ou seja, se o usuário criado no CLOCK IN for Es decir, si el usuario creado en el CLOCK IN fuera [email protected], também deverá ser exatamente también debe ser exactamente [email protected] IdP-provedor de identidade homologado, seja Azure ou proveedor de identidad homologado, ya sea Azure o Totvs Identity (Fluig).
- Contas que não tenham essa correspondência não poderão mais acessar os aplicativos do CLOCK IN ou, se existirem no IdP e não no ambiente do CLOCK IN, não terão seus parâmetros de ambiente atualizados (configuração 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.).
| Expandir | ||
|---|---|---|
| ||
Para mais detalhes acesse nosso artigomás detalles acceda a nuestro artículo: 3. Criação Creación automática de usuários Acesse os Settings do Backoffice, vá até a cessão de Usuários - Criação Automática e verifique qual a Regra de Login utilizada. Essa regra é imposta a todo cadastro de Empregado do Backoffice. 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 Caso a criação automática seja baseada no e-mail do cadastro do empregado, é importante que seja exatamente o do cadastro do Azure ou Totvs Identity (Fluig). Exemplo Ejemplo Azure:
Exemplo Ejemplo Totvs Identity (Fluig):
|
| Expandir | ||
|---|---|---|
| ||
Para mais detalhes acesse nosso artigo: más detalles acceda a nuestro artículo: 2. Cadastro Registro de Usuáriosusuarios Para casos de usuários genéricos para tablets e outros, o procedimento se mantém o mesmo, sua criação deverá ser realizada exclusivamente através do Backoffice, porém o LOGIN utilizado também deve existir e ser exatamente igual no Azure ou 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).
|
| Expandir | |||
|---|---|---|---|
| |||
| Os usuários que estiverem logados no Los usuarios que estuvieran conectados al CLOCK IN MOBILE antesantes de habilitar o SSO permanecerão conectados até que o TOKEN de autenticação seja revogado, mesmo que esse usuário não tenha vinculo com nenhum usuário do IdP-provedor de identidade.O aplicativo CLOCK IN MOBILE utiliza o login por SSO ou email/senha apenas como sendo uma porta de entrada para geração de um TOKEN. Esse TOKEN, por sua vez, é utilizado para gerar o que chamamos de API Key e está é utilizada para se comunicar com a Plataforma Carol em outras requisições, como o envio de marcações realizadas através do app CLOCK IN MOBILE. A API Key só vai expirar caso seja revogada ou o usuário seja inativado/removido. Resumindo, o token gerado pela IdP-provedor de identidade é usado apenas para que validemos a entrada e obtenhamos o API Key. Uma vez com o API Key, ele não vai expirar. |
| Expandir | ||
|---|---|---|
| ||
Estes usuários perderão acesso ao ambiente e aos aplicativos, mas permanecerão ativos internamente na Plataforma Carol, ficando a critério do cliente desativá-los através do Backoffice. |
03. PORQUE CRIAR USUÁRIOS NO CLOCK IN SE O ACESSO É VIA AZURE/TOTVS IDENTITY?
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.
|
| Expandir | ||
|---|---|---|
| ||
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 usuário deve estar vinculado a um Tenant/Ambiente dentro da Plataforma Carol para que consiga realizar o Login no aplicativo do 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 e y/ou o Backoffice;
- Toda parte de segurança de acesso da seguridad de acceso de la Plataforma Carol e do y del Clock In estão están vinculadas ao al Grupo de Acesso dos usuários. Para mais detalhes acesse nosso artigo: Configurando acceso de los usuarios. Para más detalles acceda a nuestro artículo: Configuración del Data Access Level (Privacidade Privacidad de Dadosdatos) ou o 2. Data Access Level (DAL);
- Os parâmetros de ambiente utilizados pelo Los parámetros de entorno utilizados por el Clock In Mobile, Clock In Web e y/ou o Backoffice ficam vinculados ao usuário. Esses parâmetros de ambiente são utilizados para o quedan vinculados al usuario. Estos parámetros de entorno se utilizan para el Data Access Level, para definir se aquele usuário vai utilizar Cerca Virtual a nível e Local e/ou Empresa, se ele terá acesso ou não ao Backoffice, se ele terá acesso ou não a Interface de usuário da Plataforma Carol, entre outras features do produto.
...
- 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
...
Quando há usuários previamente criados no CLOCK IN que não possuem correspondência no provedor de identidade (IdP) habilitado, como Azure AD ou o Totvs Identity, é necessário inativá-los es necesario desactivarlos manualmente para evitar problemas de acessoacceso. Esta inativação pode ser realizada diretamente no desactivación puede realizarse directamente en el Backoffice.
Para inativar um usuário desactivar un usuario individualmente, siga os passos abaixoestos pasos:
- Acesse o Acceda a Backoffice > UsuáriosUsuarios.
- Localize o usuário desejado.
- Selecione o usuário e proceda com a inativação.
É importante garantir que apenas usuários que não possuem correspondência no IdP sejam inativados, para evitar interrupções de acesso indevidas.
...
- Ubique el usuario deseado.
- 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
...
Quando há um grande número de usuários sem correspondência no provedor de identidade e entenda que a inativação manual inviável e/ou para realizar a inativação de vários usuários simultaneamente, é necessário envolver o time de serviços.Nesse caso, entre em contato com a ESN e solicite uma proposta de serviços para a inativação coletiva dos usuários.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas