01. VISÃO GERAL

O login do produto para o Datasul Smart Services (DSS) deve possuir conceitos unificados para que seu fluxo seja simples, seguro e de fácil utilização.

02. PREMISSAS

Para que o serviço de login esteja disponível para as demais aplicações, foram estabelecidas algumas premissas: 

  1. A tela de login deve estar hospedada no login-service e não nos clientes, pois deste modo não haverá a necessidade de replicar o conteúdo estático da tela em cada aplicação e facilitará sua reutilização;
  2. A autenticação do mesmo será realizado com conceitos do OAuth2, fluxo Resource Owner Password Credentials (ROPC);
    1. Este fluxo estará disponivel enquanto a migração da autenticação com o Fluig Identity não estiver concluída;
    2. Após a liberação do Fluig Identity, será considerada a troca deste modelo de autenticação, possivelmente para o modelo Open ID Connect (OIDC).
  3. Para o DSS haverá apenas um cadastro de ROPC do Datasul, visto que, para o sistema apenas esse modelo é necessário;
    1. O provider de autenticação padrão será o banco EMS (login interno com o ERP Datasul);
    2. Será considerado também o provedor de autenticação LDAP.
  4. Integrações machine-to-machine também serão consideradas, para estes casos, utilizar o fluxo Client Credentials (CC), também disponível em nosso login-service;
  5. A etapa de autorização de acesso será realizada pela validação do token, sendo que este já está implementada na arquitetura do DSS;
  6. Por medidas de segurança, o token de acesso (access_token) expirará após um determinado período de tempo;
    1. Como o token de acesso perderá a validade, será necessário a utilização do token de atualização (refresh_token), onde o mesmo conterá um tempo de expiração maior.

03. FLUXOS DE AUTENTICAÇÃO / AUTORIZAÇÃO

O fluxo de autenticação pode seguir alguns caminhos, de acordo com sua requisição inicial e sua necessidade.

A seguir serão apresentados alguns exemplos de fluxos:

FLUXO 1 - Caminho feliz


  1. O usuário, no navegador, entra na tela de login web
  2. Após a inserção das credenciais, é efetuada uma requisição ao login-service (*1)
  3. Caso a autenticação seja realizada com sucesso, será retornada informações dos tokens (access_token e refresh_token) (*2) e será automaticamente redirecionado para o aplicativo padrão (portais, menu, dashboard, entre outros) (*3)
  4. Com os tokens devidamente armazenados, eles são enviados para o acesso a um determinado endpoint (*4)
  5. O DSS architeture efetuará a validação do token enviado (*4) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*5 e *6).

FLUXO 2 - Requisição direta ao front-end



  1. O usuário, no navegador, acessa diretamente um endereço correspondente a uma tela front-end (menu, dashboard, portal, entre outros) (*1);
  2. O front-end tenta acessar um endpoint seguro (*2);
  3. Na validação do endpoint, foi verificado que não existem tokens (acesso e atualização) (*2), sendo retornado o erro HTTP Status 401 (não autorizado) (*3);
  4. O front-end interpreta este tipo de erro e redireciona para a tela de login web para que as credenciais sejam informadas (*4);
  5. Após a inserção das credenciais, é efetuada uma requisição ao login-service (*5);
  6. Caso a autenticação seja realizada com sucesso, será retornada informações dos tokens (access_token e refresh_token) (*6) e será automaticamente redirecionado para o endereço de back_to correspondente ao front-end que efetuou o redirecionamento na etapa 4 (*7);
  7. Com os tokens devidamente armazenados, eles são enviados novamente para o endpoint seguro (*8);
  8. O DSS architeture efetuará a validação do token enviado (*8) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*9 e *10).

FLUXO 3 - Requisição com um token inválido e/ou expirado


  1. O front-end tenta acessar um endpoint seguro (*1);
  2. Na validação do endpoint, foi verificado que o token está inválido e/ou expirado (*2), sendo retornado o erro HTTP Status 401 (não autorizado) (*2);
  3. O front-end interpreta este tipo de erro e reconhece que existe um refresh_token, portanto tenta efetuar a renovação do token por intermédio do login-service (*3);
  4. Caso a validação do refresh_token seja concluída com sucesso, serão retornados novos tokens (access_token e refresh_token) (*4)
  5. Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*5);
  6. O DSS architeture efetuará a validação do token enviado (*8) e caso esteja tudo OK, o acesso será autorizado com a requisição concluída (*6).

04. ARMAZENAMENTO DOS TOKENS

Os tokens devem ser armazenados para não houver a necessidade de efetuar sua geração a cada requisição, quanto ao armazenamento, foram consideradas três propostas:

sessionStorage

PRÓSCONTRAS
  • Fácil interação
  • Capacidade de armazenamento maior 5-10MB
 
  • Possível inviabilidade devido a cross domain
  • Abertura de uma nova URL é considerada outra sessão, portanto os dados não são repassados

Devido a característica do DSS, onde os serviços serão distribuídos em diversas portas, esta opção se torna inviável para utilização.

localStorage

PRÓSCONTRAS
  • Fácil interação
  • Capacidade de armazenamento em 5MB.
  •  Necessidade de gerenciar um cross domain pois o storage é disponível por host e porta
  • Opções de visibilidade com o uso de Iframes
    • Sincronização de eventos (abertura da tela com set da localStorage em cada projeto para receber o parametro)

Com o uso de Iframes, é possível seguir o conceito de compartilhamento dos dados conforme diagrama abaixo:

Foram realizados POCs para verificar a visibilidade da informação do token na localStorage, sendo seus resultados apresentados a seguir:

Situação 1: Login web e front-end com o mesmo domínio (com portas diferentes), onde o endereço localhost:4200 (login web) e localhost:4400 (front-end).


Situação 2: Login web e front-end com domínios e portas diferentes, onde o endereço localhost:4200 (login web) e 172.16.42.7:4400 (front-end). Nesta situação, devido a questões de segurança não foi possível compartilhar as informações do localStorage.


Situação 3: Login web como main-domain e front-end como sub-domain e portas diferentes, onde o endereço dss.com:4200 (login web) e menu.dss.com:4400 (front-end).

Cookies

PRÓSCONTRAS
  • Alinhado com futuras entregas do Identity
  • Visibilidade entre domínios
  • Configurações de visibilidade de acordo com regras de segurança dos próprios cookies
  • Limitação em 4KB
  • Possivel implementação de um cookie opaco
  • Pode ter uma lentidão para regatar o valor do cookie

Foram realizados POCs para verificar a visibilidade da informação no cookie, sendo seus resultados apresentados a seguir:

Situação 1: Login web e front-end com o mesmo domínio (com portas diferentes), onde o endereço localhost:4200 (login web) e localhost:4400 (front-end).


Situação 2: Login web e front-end com domínios e portas diferentes, onde o endereço localhost:4200 (login web) e 172.16.42.7:4400 (front-end). Nesta situação, devido a questões de segurança não foi possível compartilhar as informações do cookie.

Para este tipo de situação, teoricamente uma alternativa seria parametrizar o atributo SameSite='None', porém para isso é obrigatório que o Cookie possua também o parâmetro Secure=true, o que pode impactar na obrigação de instalar todos os serviços do DSS com o protocolo HTTPS. 


Situação 3: Login web como main-domain e front-end como sub-domain e portas diferentes, onde o endereço dss.com:4200 (login web) e menu.dss.com:4400 (front-end).

05. SERVIÇO DE LOGIN

O serviço de login é iniciado com o uso do spring-boot.

A seguir são apresentadas as propriedades específicas deste serviço que podem ser configuradas no arquivo application.properties.

PropriedadeDescrição
totvs.jwt.audienceAudiência utilizada para a geração e autorização do token JWT.
totvs.jwt.expirationTempo de expiração do token JWT (em segundos).
totvs.jwt.tenantId

Valor parametrizável da claim tenantId

(Pendente Issue: DFWKDATASUL-4723)

As propriedades abaixo presentes no produto DTS4THF foram descontinuadas para o uso no modelo DSS.

PropriedadeDescrição
totvs.jwt.audience.extIdentificador da audiência quando utilizado o acesso por servidor externo
totvs.jwt.cert.aliasAlias para decodifcação do token JWT (utilizado quando existir um certificado próprio)
totvs.jwt.cert.aliasdefaultAlias padrão para decodificação do token JWT
totvs.jwt.cert.defaultCertificado padrão para decodificação do token JWT

Após a inicialização do mesmo, estará disponível tanto a interface da tela de login (front-end) quanto o serviço de autenticação dos usuários (back-end). 

06. ANEXOS

RFC000032 - Autenticação Aplicações On-Premises (RASCUNHO)


app.component.ts do front-end para recebimento do localStorage