...
- Visão Geral
- .
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:
- 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;
- A autenticação do mesmo será realizado com conceitos do OAuth2, fluxo Resource Owner Password Credentials (ROPC);
- Este fluxo estará disponivel enquanto a migração da autenticação com o Fluig Identity não estiver concluída;
- 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)
...
- .
- Para o DSS haverá apenas
...
- um cadastro de ROPC do Datasul, visto que, para o sistema apenas esse modelo é necessário
...
- ;
- O provider de autenticação padrão será o banco
...
- EMS (login interno com o ERP Datasul);
- Será considerado também o provedor de autenticação LDAP.
- 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;
- A etapa de autorização de acesso será realizada pela validação do token, sendo que este já está implementada na arquitetura do DSS;
- Por medidas de segurança, o token de acesso (access_token) expirará após um determinado período de tempo;
- 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 |
|---|
 Image Added
|
- O usuário, no navegador, entra na tela de login web
- Após a inserção das credenciais, é efetuada uma requisição ao login-service (*1)
- 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)
- Com os tokens devidamente armazenados, eles são enviados para o acesso a um determinado endpoint (*4)
- 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 |
|---|
 Image Added
|
- O usuário, no navegador, acessa diretamente um endereço correspondente a uma tela front-end (menu, dashboard, portal, entre outros) (*1);
- O front-end tenta acessar um endpoint seguro (*2);
- 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);
- O front-end interpreta este tipo de erro e redireciona para a tela de login web para que as credenciais sejam informadas (*4);
- Após a inserção das credenciais, é efetuada uma requisição ao login-service (*5);
- 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);
- Com os tokens devidamente armazenados, eles são enviados novamente para o endpoint seguro (*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
|
- O front-end tenta acessar um endpoint seguro (*1);
- 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);
- 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);
- Caso a validação do refresh_token seja concluída com sucesso, serão retornados novos tokens (access_token e refresh_token) (*4)
- Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*5);
- 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ÓS | CONTRAS |
|---|
- 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ÓS | CONTRAS |
|---|
- 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)
| Informações |
|---|
| 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). 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ÓS | CONTRAS |
|---|
- 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
| Informações |
|---|
| 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 |
|---|
| 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.
| Propriedade | Descrição |
|---|
| totvs.jwt.audience | Audiência utilizada para a geração e autorização do token JWT. |
| totvs.jwt.expiration | Tempo de expiração do token JWT (em segundos). |
| totvs.jwt.tenantId | Valor parametrizável da claim tenantId (Pendente Issue: DFWKDATASUL-4723) |
| Nota |
|---|
|
As propriedades abaixo presentes no produto DTS4THF foram descontinuadas para o uso no modelo DSS. | Propriedade | Descrição |
|---|
| totvs.jwt.audience.ext | Identificador da audiência quando utilizado o acesso por servidor externo | | totvs.jwt.cert.alias | Alias para decodifcação do token JWT (utilizado quando existir um certificado próprio) | | totvs.jwt.cert.aliasdefault | Alias padrão para decodificação do token JWT | | totvs.jwt.cert.default | Certificado 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 |
|---|
| name | RFC000032.pdf |
|---|
| height | 250 |
|---|
|
app.component.ts do front-end para recebimento do localStorage
| View file |
|---|
| name | app.component.ts |
|---|
| height | 250 |
|---|
|
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
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:
