Linha Datasul

Árvore de páginas

Versões comparadas

Versão antiga 2

changes.mady.by.user Ricardo Suzuki Junior

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Ricardo Suzuki Junior

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

CONTEÚDO

...

Índice

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.

...

  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 dois 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

Image Modified

code

1.


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

FLUXO 2

Bloco de código
1. O usuário, no navegador, acessa diretamente um endereço correspondente a uma tela
2.
  1. Login-service ao autenticar um usuário deve fazer o redirect para a url default ou o backto caso tenha sido informado

1. O USUÁRIO, no NAVEGADOR, acessa o endereço do FRONTEND
2. O FRONTEND tenta acessar uma API SEGURA do BACKEND
3. O BACKEND verifica que a requisição não tem um TOKEN DE APLICAÇÃO e retorna um 401 (NÃO
AUTORIZADO)
4. O FRONTEND verifica que houve um retorno 401, que não existe um REFRESH TOKEN e o TOTVS
Identity está disponível

4. O FRONTEND verifica que houve um retorno 401, que não existe um REFRESH TOKEN e o TOTVS
Identity está disponível
5. O FRONTEND gera um STATE e chama a API de AUTHORIZE do ACCOUNTS passando:
grant_type = authorization_code
state = < STATE gerado pelo FRONTEND >
response_type = code
scope = < id da APLICAÇÃO >
client_id = < id da credencial daquela instância da APLICAÇÃO >
redirect_uri = < url da APLICAÇÃO que fará a troca do token >
6. O API de AUTHORIZE do ACCOUNTS valida se a REDIRECT_URI é válida para o CLIENT_ID informado
7. O API de AUTHORIZE do ACCOUNTS gera um CODE e retorna um redirect para a tela de LOGIN do
IDENTITY
8. O IDENTITY apresenta a tela de LOGIN para o USUÁRIO
9. O USUÁRIO informa suas CREDENCIAIS:
e-mail
password

  1. Para timeout, logout, erros de login o redirecionamento deve ser feito automaticamente para a url padrão cadastrada no ROPC. Podemos usar a arquitetura do serviço para isso, mas, precisamos analisar melhor para não deixar altamente acoplada a solução.
  1. Para timeout, logout, erros de login o redirecionamento deve ser feito automaticamente para a url padrão cadastrada no ROPC. Podemos usar a arquitetura do serviço para isso, mas, precisamos analisar melhor para não deixar altamente acoplada a solução.
  1. Ainda teremos que avaliar sobre o refresh token e a melhor estratégia para esse fluxo.

02. ARMAZENAMENTO DOS TOKENS

...

- Requisição direta ao front-end


Image Added


  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

Image Added


  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
  • 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
titleAviso

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

STORAGE (localStorage)

 - Fácil interação
 - Capacidade em 5MB - Necessidade
  • de gerenciar um cross domain pois o storage é disponível por host e porta
 - Opções Iframe
   -
  • 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)
Informações
titlePOC de Iframe

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

Image Added

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

Image Added


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)

COOKIES

. Nesta situação, devido a questões de segurança não foi possível compartilhar as informações do localStorage.

Image Added


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

Image Added

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

04. FLUXO DE ATUALIZAÇÃO DO TOKEN

Informações
titlePOC 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).

Image Added


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.

Image Added

Nota
titleNota

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

Image Added

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)

Nota
titleNota

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)

View file
nameRFC000032.pdf
height250


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

View file
nameapp.component.ts
height250
2. O BACKEND verifica que a requisição tem um TOKEN DE APLICAÇÃO mas o mesmo está EXPIRADO e
retorna um 401 (NÃO AUTORIZADO)
3. O FRONTEND verifica que houve um retorno 401, que existe um REFRESH TOKEN (que é um COOKIE)
4. O FRONTEND chama a API de TOKEN da APLICAÇÃO informando: