...
A seguir serão apresentados alguns exemplos de fluxos:
1. FLUXO 1 - Caminho feliz |
---|
Image Modified |
Bloco de código |
2.
3.
4.
5. FLUXO 2 - Requisição direta ao front-end |
---|
Image Modified |
Bloco de código |
1.
2.
3.
4.
5.
6.
7.
8. FLUXO 3 - Requisição com um token inválido e/ou expirado |
---|
IMAGEMImage Added |
Bloco de código |
1. 2
2. 3
3. válido 5
4. token de atualização seja concluída com sucesso, serão retornados novos tokens - refresh_token seja concluída com sucesso, serão retornados novos tokens (access_token
|
6)
5. Com os tokens devidamente atualizados em seu armazenamento, eles são enviados novamente para o endpoint seguro (*8);
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 (*9 e *10- 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
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 |
---|
|