Linha Datasul

Árvore de páginas

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

Aviso

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)

POC de Iframe

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

POC de Cookies

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.

Nota

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

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


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

app.component.ts