...
A seguir serão apresentados alguns exemplos de fluxos:
FLUXO 1 - Caminho feliz |
|---|
 Image Modified
|
- 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 Modified
|
- 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 Modified
|
- O front-end tenta acessar um endpoint seguro (*
|
2- 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) (*
|
3- 2);
- O front-end interpreta este tipo de erro e reconhece que existe um refresh_token
|
válido- , portanto tenta efetuar a renovação do token por intermédio do login-service (*
|
5- 3);
- Caso a validação do refresh_token
|
de atualização - seja concluída com sucesso, serão retornados novos tokens (access_token e refresh_token) (*
|
6- 4)
- Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*
|
8- 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 (*
|
9 e *1004. 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
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 |
|---|
| 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.
| |
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)
|
COOKIES
| 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
- - 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
|
- - - 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 |
|---|
|
