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 |
---|
|
FLUXO 2 - Requisição direta ao front-end |
---|
|
FLUXO 3 - Requisição com um token inválido e/ou expirado |
---|
|
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 |
---|---|
|
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 |
---|---|
|
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ÓS | CONTRAS |
---|---|
|
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. 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)
app.component.ts do front-end para recebimento do localStorage