Skip to main content

Autenticação

A autenticação é orquestrada a partir de uma instância Keycloak dedicada, definida em outro contêiner e com domínio próprio. O esquema de login faz uso de single sign-on, de modo que não é necessário realizar mais de um login para fazer uso das features do servidor Bokeh e do frontend. Para isso, são definidos dois clients separados sob um mesmo realm.

O fluxo de login esperado de um usuário do sistema é como o descrito pela figura 1.

Figura 1 - Fluxo de login esperado de um usuário do sistema

As rotas de gráficos estão protegidas pela autenticação via Keycloak em ambos os serviços. Isto significa dizer que um usuário deve estar registrado no Keycloak para que ele possa acessar os gráficos. Caso uma requisição seja feita a /graficos/* no serviço JS ou a /bokeh/bkapp?codigo=*&tecnica=*&date=* sem que haja uma sessão corrente, a página será um fallback que permite ao usuário logar no realm.

A autenticação atual não impede requisições à API para a obtenção de dados, mas requer o uso de um id de usuário do tipo UUID (obtido a partir do token de acesso) para o registro de adequações.

Testagem da autenticação

Para testar a autenticação, são necessários alguns passos de configuração do Keycloak e de variáveis de ambiente de ambos os serviços de front-end para que o funcionamento ocorra sem problemas. A instância keycloak deverá ter dois clients dentro do realm criado - sipam-client e bokeh-client. O bokeh-client necessita de uma configuração especial para que ele não retorne o código de status de sessão ou o ISS dentro da url de resposta de autenticação.

Tratando sobre variáveis de ambiente, o módulo NextAuth.js dentro do sistema Javascript depende de uma disposição similar a abaixo (.env.local):

API_URL="http://localhost:8000"
BACKEND_URL="http://localhost:7788"
BOKEH_URL="http://localhost:5006"
NEXT_PUBLIC_KEYCLOAK_URL="http://localhost:8080"
KEYCLOAK_ID="sipam-client"
NEXT_PUBLIC_REALM_NAME="sipam"
KEYCLOAK_SECRET=generate-secret
KEYCLOAK_ISSUER="http://localhost:8080/realms/sipam"
NEXTAUTH_SECRET=generate-secret
END_SESSION_URL="http://localhost:8080/realms/sipam/protocol/openid-connect/logout"
REFRESH_TOKEN_URL="http://localhost:8080/realms/sipam/protocol/openid-connect/token"
NEXTAUTH_URL="http://localhost:3000"
LOG_LEVEL='info'

O exemplo acima usa dos endereços que serão gerados com o docker-compose. O segredo do realm pode mudar, portanto ele deve ser inserido novamente.

A variável NEXTAUTH_SECRET é um segredo necessário para o Nextauth.js funcionar adequadamente em produção. Para tanto, ele pode ser gerado com o comando abaixo:

npx auth secret

O segredo gerado deve ser substituído em NEXTAUTH_SECRET sem aspas por se tratar de um arquivo .env.local.

O mesmo comando pode ser utilizado para a configuração de variáveis de ambiente a serem usadas pelo sistema Python, que possuem uma disposição similar à abaixo:

API_URL=http://localhost:8000

BOKEH_COOKIE_SECRET=generate-secret
BOKEH_HOST=http://localhost:5006
KEYCLOAK_HOST=http://localhost:8080
KEYCLOAK_REALM=sipam
KEYCLOAK_CLIENT_ID=bokeh-client
KEYCLOAK_CLIENT_SECRET=generate-secret

Novamente, é necessário conferir o segredo do cliente Keycloak para que os tokens possam ser devidamente gerados e gerenciados pelo sistema.

Histórico de versão

VersãoDataDescriçãoAutorRevisor
1.009/12/2024Adição do arquivo à documentaçãoCássio ReisFelipe M.