TOTVS Clock In

Atalhos

Árvore de páginas

01. VISÃO GERAL


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 Azure Active Directory ou Totvs Identity (Fluig) como provedores de identidade (IDP).


02. CRIAÇÃO DE USUÁRIOS PARA CORRESPONDÊNCIA DE CONTAS


  • Usuários criados automaticamente ou através do CLOCK IN BACKOFFICE devem ter uma conta/e-mail correspondente no IdP-provedor de identidade homologado, seja Azure ou Totvs Identity. Ou seja, se o usuário criado no CLOCK IN for [email protected], também deverá ser exatamente [email protected] IdP-provedor de identidade homologado, seja Azure ou 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 de DAL, GEOFENCE, SELF CLOCK IN, etc).


Para mais detalhes acesse nosso artigo: 3. Criação 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.


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 Azure:

Exemplo Totvs Identity (Fluig):


Caso utilize qualquer outra regra de Login, é importante realizar a mesma validação. E-mails FALSOS/FAKE, criados a partir da matrícula ou outros, que sejam utilizados para Login no CLOCK IN deixarão de funcionar, a menos que incluam eles também o Azure ou Fluig.

Para mais detalhes acesse nosso artigo: 2. Cadastro de Usuários

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 Totvs Identity (Fluig).

Os usuários que estiverem logados no CLOCK IN MOBILE antes 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.


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?


  • Todo usuário deve estar vinculado a um Tenant/Ambiente dentro da Plataforma Carol para que consiga realizar o Login no aplicativo do Clock In Mobile, Clock In Web e/ou Backoffice;
  • Toda parte de segurança de acesso da Plataforma Carol e do Clock In estão vinculadas ao Grupo de Acesso dos usuários. Para mais detalhes acesse nosso artigo: Configurando Data Access Level (Privacidade de Dados) ou 2. Data Access Level (DAL);
  • Os parâmetros de ambiente utilizados pelo Clock In Mobile, Clock In Web e/ou Backoffice ficam vinculados ao usuário. Esses parâmetros de ambiente são utilizados para o 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.

04. INATIVAÇÃO DE USUÁRIOS EXISTENTES ANTES DE HABILITAR O AZURE/TOTVS IDENTITY


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 Totvs Identity, é necessário inativá-los manualmente para evitar problemas de acesso. Esta inativação pode ser realizada diretamente no Backoffice.

Para inativar um usuário individualmente, siga os passos abaixo:

  1. Acesse o Backoffice > Usuários.
  2. Localize o usuário desejado.
  3. 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.




05. INATIVAÇÃO COLETIVA DE USUÁRIOS ANTES DE HABILITAR O AZURE/TOTVS IDENTITY


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.



  • Sem rótulos